Integration testing: requests
This course covers request specs in a Rails app, drawing on the app's own spec/requests/ files. It explains what type: :request sets up and how get, post, patch and delete send a request through the router, middleware and controller without a browser. It covers response assertions with have_http_status, response.body and response.status. It also compares request specs with system specs and controller specs. Later lessons cover a reusable sign_in helper, CRUD and JSON examples, and tests for access control and failure paths.
What you'll learn
- ✓What the type: :request tag sets up and which HTTP verb helpers this app uses
- ✓Checking responses with have_http_status, response.body and response.status
- ✓How request specs differ from system specs and controller specs
- ✓A reusable sign_in helper scoped to request specs with config.include
- ✓Asserting database changes in CRUD specs and parsed JSON in API specs
- ✓Testing access control, required login and validation failures
What a request spec actually is
The course right before this one, System testing: Capybara, spent seven lessons on type: :system: a browser, JavaScript and Capybara's DSL. It closed by naming the layer underneath: this app's spec/requests/, dozens of files and a few hundred examples that already prove server-side correctness…
Read the full lesson free →Curriculum
7 lessonsWhat a request spec actually is
Explains the type: :request tag, the HTTP verb helpers this app uses, and the full server-side round trip.
The response assertions this app's specs make
Covers have_http_status, response.body and response.status, and notes that this app parses JSON by hand instead of using parsed_body.
Request spec vs. system spec vs. controller spec: three approaches, one discouraged
Compares request, system and controller specs, and explains why the Rails and RSpec teams discourage controller specs.
This app's reusable sign_in helper
Walks through the sign_in helper, a real login POST included only in request specs through config.include.
CRUD and JSON-API examples, from this app's specs
Shows CRUD specs that assert database changes and JSON specs that parse the response body, including a forged-output rule.
Testing what shouldn't happen: access control and failure paths
Tests access control in both directions, required login redirects and validation failures with the unprocessable_content status.
Putting it together: the round trip, and where the tour of this app's tests goes next
Reviews the course and presents a pure-Ruby challenge that mirrors how have_http_status maps symbols to status ranges.