📖 Scenario: You are building a simple blog application in Rails. You want to make sure that users can visit the homepage and see the list of posts correctly.
🎯 Goal: Create an integration test that visits the homepage and checks that the page shows the title of a post.
📋 What You'll Learn
Create a post record with a specific title
Set up a test to visit the homepage path
Check that the page contains the post title text
Use Rails integration test syntax with get and assert_select
💡 Why This Matters
🌍 Real World
Integration tests help ensure that different parts of a web app work together correctly, like visiting pages and seeing expected content.
💼 Career
Rails developers use integration tests to catch bugs early and maintain app quality, which is important for professional web development.
Progress0 / 4 steps
1
Create a post record
Create a post record with the title 'My First Post' using Post.create! and assign it to a variable called post.
Ruby on Rails
Hint
Use Post.create!(title: 'My First Post') and assign it to post.
2
Set up the integration test class
Create a class called PostsFlowTest that inherits from ActionDispatch::IntegrationTest.
Ruby on Rails
Hint
Use class PostsFlowTest < ActionDispatch::IntegrationTest to start the test class.
3
Write a test method to visit homepage
Inside the PostsFlowTest class, write a test method called test_visiting_homepage that uses get root_path to visit the homepage.
Ruby on Rails
Hint
Define def test_visiting_homepage and call get root_path inside it.
4
Assert the post title appears on the page
Inside the test_visiting_homepage method, add an assert_select that checks for an h1 element containing the text 'My First Post'.
Ruby on Rails
Hint
Use assert_select 'h1', 'My First Post' to check the page content.
Practice
(1/5)
1. What is the main purpose of integration tests in a Rails application?
easy
A. To test individual methods in models
B. To test only the views without backend logic
C. To check database schema correctness
D. To check how different parts of the app work together from a user's perspective
Solution
Step 1: Understand integration test scope
Integration tests simulate user actions and check multiple parts working together.
Step 2: Compare options with integration test purpose
Only To check how different parts of the app work together from a user's perspective describes testing how parts work together from a user's view.
Final Answer:
To check how different parts of the app work together from a user's perspective -> Option D
Quick Check:
Integration tests = user perspective checks [OK]
Hint: Integration tests simulate user actions across components [OK]
Common Mistakes:
Confusing integration tests with unit tests
Thinking integration tests only check views
Assuming integration tests test database schema
2. Which of the following is the correct way to start an integration test class in Rails?
easy
A. class UserFlowsTest < ApplicationController
B. class UserFlowsTest < ActionDispatch::IntegrationTest
C. class UserFlowsTest < ActiveRecord::Base
D. class UserFlowsTest < ActionController::TestCase
Solution
Step 1: Identify the base class for integration tests
Rails integration tests inherit from ActionDispatch::IntegrationTest.
Step 2: Check each option's base class
Only class UserFlowsTest < ActionDispatch::IntegrationTest inherits from ActionDispatch::IntegrationTest, others are for models or controllers.
Final Answer:
class UserFlowsTest < ActionDispatch::IntegrationTest -> Option B
Quick Check:
Integration test class inherits ActionDispatch::IntegrationTest [OK]
Hint: Integration tests inherit from ActionDispatch::IntegrationTest [OK]
Common Mistakes:
Using ActiveRecord::Base which is for models
Using ApplicationController which is for controllers
Using ActionController::TestCase which is for controller tests
3. Given this integration test code snippet:
test "visit home page" do
get root_path
assert_response :success
assert_select "h1", "Welcome"
end
What does assert_select "h1", "Welcome" check?
medium
A. That the page contains an <h1> tag with text exactly 'Welcome'
B. That the page has any <h1> tag regardless of text
C. That the response status is 404
D. That the page redirects to another URL
Solution
Step 1: Understand assert_select usage
assert_select checks HTML elements and their content in the response body.
Step 2: Analyze the parameters "h1" and "Welcome"
It looks for an <h1> tag with text exactly matching "Welcome".
Final Answer:
That the page contains an <h1> tag with text exactly 'Welcome' -> Option A
Quick Check:
assert_select checks HTML element and text [OK]
Hint: assert_select checks HTML tags and their content [OK]
Common Mistakes:
Thinking assert_select only checks tag presence without text
Confusing assert_response with assert_select
Assuming assert_select checks redirects
4. Identify the error in this integration test code:
test "create user" do
post users_path, params: { user: { name: "Alice" } }
assert_redirected_to user_path(@user)
end
medium
A. params hash syntax is invalid
B. Missing get request before post
C. Using @user without defining or assigning it in the test
D. Incorrect HTTP verb; should use get instead of post
Solution
Step 1: Check variable usage in assertion
The test asserts redirect to user_path(@user), but @user is never set.
Step 2: Understand how to get created user
After post, the created user should be fetched from controller or database, not assumed as @user.
Final Answer:
Using @user without defining or assigning it in the test -> Option C
Quick Check:
Undefined @user causes error in redirect assertion [OK]
Hint: Define variables before using in assertions [OK]
Common Mistakes:
Assuming @user is auto-set after post
Confusing HTTP verbs for create actions
Incorrect params hash structure
5. You want to write an integration test that submits a login form and then checks if the user is redirected to their dashboard page. Which sequence of methods correctly simulates this flow?
hard
A. post login_path, params: { session: { email: "user@example.com", password: "secret" } } followed by assert_redirected_to dashboard_path
B. get login_path followed by assert_response :success and then get dashboard_path
C. assert_redirected_to login_path followed by post dashboard_path
D. post dashboard_path with user params followed by assert_response :redirect
Solution
Step 1: Identify correct HTTP verb for form submission
Login forms usually submit with POST, so use post with params.
Step 2: Check correct assertion after login
After successful login, user should be redirected to dashboard, so assert_redirected_to dashboard_path is correct.
Final Answer:
post login_path, params: { session: { email: "user@example.com", password: "secret" } } followed by assert_redirected_to dashboard_path -> Option A
Quick Check:
POST login + assert redirect to dashboard [OK]
Hint: Use post for form submit, then assert_redirected_to for redirect [OK]
Common Mistakes:
Using get instead of post for form submission
Checking response success instead of redirect
Posting to dashboard_path instead of login_path
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.