Lesson Tuesday

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.

Configuring Capybara

To configure Capybara in our Rails project, we'll follow these steps:

  1. Add gem 'capybara' to your Gemfile in the test section.
  2. Run $ bundle install in the terminal.
  3. Add require 'capybara/rails' at the top of the spec/rails_helper.rb file after require 'rspec/rails' If it's added before require 'rspec/rails', there will be errors).
  4. Create a spec/features folder to hold integration test files.

Sample Integration Tests

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'

  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"

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

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

Additional Resources

For more info on Capybara with RSpec and Rails, check out the Capybara README, especially the sections on Using Capybara with RSpec and The DSL.

Lesson 28 of 34
Last updated August 7, 2022