Testing ActionText without JavaScript

Rails 6 sees the introduction of ActionText, a rich text editor you can get access to with just a few lines of code. Being such a new tool in the Rails ecosystem, there isn’t much written around best practice.

In this article, I’m going to share the method I used for RSpec Feature tests to make them play nicely with ActionText.

We won’t go into how to set up and use ActionText in your Rails app. If you’re interested, I highly recommend the Rails edge guide on it.

ActionText uses Trix

Before digging in, it is worth noting that ActionText uses a tool called Trix. The folks at Basecamp made it. When researching ActionText, I found people calling it:

• Trix
• ActionText
• HasRichText
• RichText

If using ActionText, I think it is safe to say you can use these terms interchangeably.

Problems with testing ActionText

I’m sure this information will be out of date very quickly, things are moving fast when it comes to support for Rails 6 features, but right now:

• Capybara doesn’t have a nice fill_in for ActionText.
• Trix uses web components and JavaScript, it isn’t just a fancy textarea you can interact with directly
• To test ActionText you need to enable JavaScript support on your feature test.

It is this last point that I wanted to write about.

With JavaScript support in your tests enabled, you can ask Capybara to interact with the page more like a mouse user would, mimicking cursor clicks. I don’t like enabling JavaScript support unless I have to.

• I don’t particularly like using JavaScript on my sites
• It adds a slight bit of complexity to the tests
• If you aren’t using JavaScript elsewhere in the system, you’re adding extra dependencies

Deciding to test without JavaScript

I was testing a small app I was building partly to test some of the new Rails 6 features and conventions.

The only JavaScript use worthy of a test at all is the one place I’ve called ActionText.

My main reason for not using JavaScript in this particular feature spec is a philosophical one.

I’m using ActionText in it’s most standard form using all of the Rails defaults. I trust that core Rails components are tested well and because there is no custom or business logic to be tested putting too much effort into testing this is a waste of time.

I know the happy path works, I need it to work in code so I can use it as a jumping off point for more interesting tests later.

Show me the code already!

Here is the capybara code I ended up writing;

find(:xpath, "//\*[@id='article_content_trix_input_article']", visible: false).set('My awesome article')

I want to find an element with the ID article_content_trix_input_article. This ID is generated for me by Rails. In this case:

• article is my model
• content is the name I gave when setting up ActionText support by calling has_rich_text :content in the model

We pass visible: false into find because what we’re targeting is a hidden input on the screen that Trix puts content into when people interact with the main editor.

set is where we add the content. My example just needed some text to move forward, but you could add basic HTML in here to test that the “rich text” part of this rich text editor is working.

I don’t recommend this all of the time

If alarm bells went off when you saw the visible: false then I don’t blame you. I don’t like feature tests doing things that users don’t generally do.

In my particular example, I made a trade-off. I feel this code is easy to reason about, it is fast, and it tests what I care about, namely: If the fields a user can populate all end up getting populated, can the user submit the form.

If I ever find an instance where a user interacts with the Trix editor and for some reason that hidden field didn’t get populated with something, then I would introduce more thorough testing.

Change my mind

Do you have a more beautiful way of writing feature tests in RSpec that use ActionText that doesn’t require me to load in web drivers and other weird and wonderful things? Let me know via our contact page.