System Tests in Rails 5.1 is awesome

System tests were announced for Rails 5.1 a few months ago. Plethora of blog posts were written about this topic but I’m still going to write about it due to how much it improved my testing life.

For people who haven’t seen the RailsConf talk about system tests, below is the video.

What are System Tests in Rails?

Just for those who may not be familiar with the term “System Tests”, it’s just simulating real user actions in a browser, automatically clicking through various parts of your application via tests, and then asserting that certain things should have happened. One example would be, a user clicks a button, a modal pops up, and so forth.

This was always possible to do in previous version of Rails by using the capybara gem, but configuring it to work flawlessly, especially when there are a lot of JavaScript code in your application was a nightmare. Maybe other people were able to get it working well, but I never could, especially when using it with the Rails’s default testing framework . Most of the documentation on integrating capybara was based on RSpec, and even in those cases, the tests would be flakey especially when there were a lot of JavaScript interactions on the page that you were testing. Thus, in many cases, I would just not write capybara tests just due to the sheer headache of making it work.

Setting up capybara properly would involve installing capybara, configuring it to work with the testing framework you are using, configuring database cleaner properly to get it to run properly alongside your other tests, choosing and configuring your capybara driver (poltergeist, capybara-webkit, etc.), and etc. If one setting in your configuration was off, your tests were going to be flakey.

Awesomeness of System Tests baked into Rails

The problems of manually integrating capybara to work with previous versions of Rails are completely solved with system tests. It works… out of the box… with no configuration on your part.

The way I used to test Rails applications was this:

  • Write controller tests, assert proper responses
  • Write unit tests for some critical classes
  • Write capybara tests for absolutely critical pages, and then get annoyed when tests run in a flakey manner

In some cases, I would simply not write capybara tests and rely on the QA process to catch bugs. With system tests baked into Rails, I found myself writing a ton of capybara tests just because it was much easier than before (not to mention that seeing the fast automated interactions in the browser driven by selenium is fun).

This was one of those “Ahh, I feel happy that this exists” posts. Props to the Rails team for finally baking this feature in.