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.
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.