So System Tests are a Thing Now

Part 3 System Tests

In the last post we used the Rails g scaffold command to build full CRUD functionality for our authors model. In this post we will be refactoring our work in order to implement system tests and take advantage of some of the functionality rolled into the latest version of RSpec.

After reading the first post in this series, my friend Mark Miranda pointed out that RSpec 3.7 and Rails 5.1 now includes both capybara and and database cleaner functionality. I did some reading and it sounds like the RSpec team has made some huge improvements. Furthermore, the Rails team seems to be advocating for a move from integration tests to the newer system tests. Between Mark and DHH, it looks like we'll be going back to our author integration tests and seeing just how these new fangled system tests actually work.

capybara.jpg

Tear Down

A good refactor often involves tearing code down. To begin our transition to system tests that take advantage of Rails' new integration with capybara, we'll remove one gems from our gem file. For now let's comment database_cleaner out.

# gem 'database_cleaner'

I tried doing this by also removing the capybara gem, but that just lead to RSpec skipping the feature / system test. My guess is the gem is still required, but there is some under the hood integration that we'll be benefiting from moving forward.

Next we'll add the following two configurations to our rails helper file:

# spec/rails_helper.rb
config.before(:each, type: :system) do
  driven_by :rack_test
end

config.before(:each, type: :system, js: true) do
  driven_by :selenium_chrome_headless
end

The above configurations say that for our default system tests we want to use rack_test. Rack test is the fastest driver for system tests on Rails because it does not involve opening a headless or actual browser to perform the test. Of course, that means we cannot test javascript behavior. The second configuration says that we will use selenium driver and a headless chrome browser when we flag a system test with js: true. If and when we add javascript behavior to this app, I'll go back an add the selenium webdriver gem to this project.

Next we will remove the database_cleaner support file we no longer need. Since Capybara is now part of Rails, tests using Capybara no longer have the danger of not cleaning up as expected.

$ rm spec/support/database_cleaner.rb

We edited our gem file so do not forget to run bundle:

$ bundle

System Tests

There is not much left to do to fully move our feature test to the new system test paradigm. The next step is to rename our spec/features folder to spec/system.

We can add a flag to our system test formerly known as a feature test, like this:

feature 'author CRUD', type: :system do

But, as long as we have the following line in our rails_helper file, Rails should automatically infer that tests in the spec/system folder should be treated as system tests.

config.infer_spec_type_from_file_location!

After that running rspec shows all tests passing!

Further Reading

System tests are fairly new at this point. I found two sources that helped me get through this transition in one piece. First, RSpec's official release notes confirmed for me that system tests were not just a rumor. Next, Noel Rappin's post gives a really good walk through of setting up system tests.

You can start from this point of the live blog journey by cloning / forking this branch of my bookshelf repo.