I needed JS to get out of the way so I could do basic testing
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:
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
textareayou can interact with directly
It is this last point that I wanted to write about.
- It adds a slight bit of complexity to the tests
I was testing Pin Trader Club, a Disney pins website. It is a small app I was building partly to test some of the new Rails 6 features and conventions.
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;
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:
articleis my model
contentis the name I gave when setting up ActionText support by calling
has_rich_text :contentin the model
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 in the comments or on Twitter.