A Field Guide to Integration and System Tests

The last few chapters

We spent the last few chapters focusing on testing the models and business logic of the Rails application. A web application is more than just business logic, though. So for the next few chapters, we’ll discuss tests that tackle the parts of the application that either respond to user input or output data to the user.

Input and output tests

There are many different terminologies used to describe the various flavors of input and output tests we can write. First, there are generic terms that are not inherent to Rails but are terms we might apply to any testing:

• An integration test is any test that covers more than one part of the application working together.

• An end-to-end test is a specific kind of integration test covering the system’s entire behavior from, well, end to end.

• An acceptance test is written to specify correct behavior from the customer or business perspective. Acceptance tests are often written (or at least planned) before coding even begins.

In this chapter

Within Rails, there is a significant functional distinction between integration tests that only use Rails and evaluate the results of a Rails call and those that also use a JavaScript driver to evaluate JavaScript based on simulated user actions. In this chapter, we’ll see the non-JavaScript versions. In the next, we’ll learn how to add JavaScript client behavior.

A field guide to integration and system tests

There are several different names for many specific kinds of tests:

• The Rails core testing library defines two similar types of end-to-end tests:

  • System tests, which were new in Rails 5.1, require the Capybara gem to simulate user interaction with the application and query application output.

  • Integration tests, which have always been a part of Rails, simulate user interaction and use a Rails-specific API that is less complete than Capybara. (To make it more confusing, we can add Capybara for use in integration tests if we want).

• RSpec defines basically the same kind of tests but gives them different names. RSpec has system tests that are wrappers around the Rails core system tests. Historically, most RSpec users wrote feature specs, which are end-to-end tests that typically use Capybara. RSpec also has request specs, which are basically wrappers around Rails integration tests.

Integration testing terms

Both RSpec and Rails/Minitest provide tools for testing controllers, views, mailers, background jobs, and helpers. The following table helps sort out the naming.