This is a three-part screencast playlist comparing and contrasting Cypress and Capybara. It’ll take a few hours to work through all of it, but if any of my advice can shave a few minutes off your test runs, you’ll make that productivity up in no time!
Direct links:
I hope you’ll watch and enjoy asynchronously pair programming with me as we explore writing better browser tests together. While you’re there, feel free to peruse our broader refurbishment of Test Double’s YouTube channel, too. Also, I feel obligated to ask that you please like, subscribe, and/or smash that bell icon (I apologize, I really don’t understand how YouTube works).
If you need a little more to go on before you’re ready to engage with this Content™, I’ll try to provide some context below.
What’re we talking about?
Writing automated browser tests of web applications is hard. Very hard. Think of all the things that one must consider:
- Loading test data into your data store(s)
- Starting and stopping your application’s server(s)
- Ensuring a way to thoroughly reset state between tests
- Organizing test scripts coherently & limiting duplication
- Avoiding multi-hours-long build durations
- Guarding against brittle tests & hard-to-debug failures
- Oh yeah, actually automating browser interactions
For years, the Ruby community has had such a good tool (relative to the competition) for browser automation in Capybara. Capybara is so much better than what came before it that it’s actually became a de facto standard in QA departments all over the world—at companies that otherwise don’t use Ruby at all!
Additionally, if you use Ruby on Rails, the built-in system test facility handles most of the bullet points above and pulls in Capybara to handle your tests’ browser interactions. It’s pretty sophisticated how seamless it is!
Why Cypress?
So, why consider switching to another tool like Cypress? Well, Cypress has a lot going for it:
- An interactive development environment in which to experiment with commands
- A running timeline of the state of the DOM at every step of your test
- Built-in video recording of every test run, to aid in debugging
- By running tests inside a shared browser window, there are fewer moving parts (whereas Capybara is mostly used as a wrapper around Selenium, which requires a separate driver application to manipulate a browser)
- By running in the browser, Cypress can enable more robust selections and complex interactions, and even abstractions to create your own expressive testing API
That said, this isn’t a clear-cut, one-size-fits-all decision. The best tool for you depends on a number of factors about the design of your application, the makeup of your team, and your goals in writing browser tests. That’s why it might be worth spending a few hours with me in this screencast series to consider some of the trade-offs at play.
The cypress-rails gem
One last thing: the screencast series will also walk you through the setup and use of a gem that makes Cypress easier to use with Rails apps.
While Capybara comes with Rails “for free”, some amount of glue is necessary to make Cypress play nicely with Rails—particularly around test data management. To make it easier to incorporate Cypress into your Rails app, we created the gem cypress-rails, which wraps the cypress CLI, and allows for:
- Running the cypress open and cypress run commands by first launching your Rails app in a test server
- Wrapping all of your tests’ actions inside a database transaction that can be quickly and repeatedly rolled back to avoid pollution between tests
- Exposing a route (
/rails_cypress_reset_state) and a number of initializer hooks that provide sufficient control over when and how your data is reset between tests
Last but not least, thanks to our friends Matthew Draper and Eileen Uchitelle from the Rails core team for their help in improving the gem’s transaction management abilities!
If you or your team decides to try out Cypress, if you need help with your existing Capybara tests, or if you’d like an outside opinion on full-stack testing, we have a lot of experience and advice that we’re happy to share. Feel free to reach out any time!
Related Insights
New Stanford research shows 9.5% of engineers contribute almost no visible work—but blame won’t solve the problem. Here’s how leaders can fix the root cause.
