Testing What Users Can’t See

Let’s learn to write a request test.

We'll cover the following

Setting up the test

Request tests are similar to feature tests in that they exist to test things in integration, but they differ from feature tests in their focus. They’re mostly concerned with what the user can’t see.

Note: There is an exception to this rule. If you have many feature tests that are testing variations of the same thing, you might want to move them to the request layer because they will run faster. You don’t have to, but it could improve the performance of our test by sacrificing a tiny bit of confidence.

So, for our little experiment here, we want to make sure that the application did create a user in the database, even though we see the correct messages displayed on the screen.

There might be other more useful tests, but this one should serve us well as a request test example.

$ rails g rspec:request registrations
create  spec/requests/registrations_spec.rb

We can easily create a request test with the Rails generator. It gives us a template that we can customize to our liking.

Note: This step has already been performed in the executable widget given at the end of the lesson.

One thing to note is that we’re not looking at the implementation code at all before or while we’re writing our tests. We only care about describing the behavior of the system.

The test we’ll write might already pass (because we’re using Devise), but we don’t go through the code to see if that’s the case.

We write our expectation. If it happens to be implemented already, fine. If not, we’ll implement it ourselves. Either way, we’re describing how we want the system to work.

Let’s now write the request test. We’ll start with what makes a good test case. Here’s the test code:

Create a free account to view this lesson.

By signing up, you agree to Educative's Terms of Service and Privacy Policy