Now that we've explored the basic build of a Rails app, we need to add integration testing to ensure everything is working as expected. We'll use the Capybara gem just as we did with Sinatra.
To configure Capybara in our Rails project, we'll follow these steps:
gem 'capybara'to your
$ bundle installin the terminal.
require 'capybara/rails'at the top of the
require 'rspec/rails'If it's added before
require 'rspec/rails', there will be errors).
spec/featuresfolder to hold integration test files.
Now we can create integration testing files. Let's create a few examples to test CRUD functionality for adding albums:
require 'rails_helper' describe "the add a album process" do it "adds a new album" do visit albums_path click_link 'Create new album' fill_in 'Name', :with => 'Giant Steps' fill_in 'Genre', :with => 'Jazz' click_on 'Create Album' expect(page).to have_content 'Album successfully added!' expect(page).to have_content 'Giant Steps' end it "gives an error when no name is entered" do visit new_album_path click_on 'Create Album' expect(page).to have_content "Name can't be blank" end end
Here are a couple things to note:
The filename ends in
_pages_spec.rb. This is a common naming convention for integration test file names.
Our integration tests should be separated by functionality into different files. We've named this file
add_album_pages_spec.rb and it should include all tests for the pages on adding an album. This includes tests on successfully adding an album and failing to add an album.
Integration tests run slowly, so test each flow through the application only once. This way, if the flow changes, fewer tests need to be updated. As an example, we don't go through the
visit_albums_path a second time in our second integration test. Instead, we start on the
In our first test, we can both check that the flash message works (which also verifies that the album was added) and check that the new album is listed on the page. Generally, we should have one expectation per test. However, there may be times when it's helpful to get additional information.
Only one error is tested. Model tests already cover how validations should work, so those tests do not need to be duplicated in an integration test. The integration test just tests that the model-view-controller processes are working together to produce the proper response to a request when the data isn't saved. In other words, if we have five validations, we don't need to test all of them. We just have to test one.
In general, integration tests look very similar to the integration tests we've written with Sinatra.
We should aim to write an integration test for every path through an application, making sure every page gets visited, every form gets submitted correctly one time and incorrectly one time. Our integration and unit tests should touch every line of code in our models, views and controllers. In the next section, we'll incorporate a tool that checks to see how much coverage we actually have.
One last thing: don't forget about using
save_and_open_page for debugging integration specs.
Lesson 28 of 34
Last updated August 7, 2022