Integration tests in Ruby on Rails - Step-by-Step Execution

Concept Flow - Integration tests

Write integration test

↓

Setup test data and environment

↓

Simulate user actions (visit, fill, click)

↓

Check page content and responses

↓

Pass or fail test

↓

Fix code or test if needed

↓

END

Integration tests simulate user actions across multiple parts of the app to check if they work together correctly.

Execution Sample

Ruby on Rails

test "user login flow" do
  visit login_path
  fill_in "Email", with: "[e-mail]"
  fill_in "Password", with: "secret"
  click_button "Log in"
  assert_text "Welcome, user!"
end

This test simulates a user logging in and checks if the welcome message appears.

Execution Table

Step	Action	Input/Condition	Result	Test Outcome
1	Visit login page	login_path	Login page loads	Continue
2	Fill in Email	"[e-mail]"	Email field filled	Continue
3	Fill in Password	"secret"	Password field filled	Continue
4	Click Log in button	Submit form	Form submitted, server processes login	Continue
5	Check page content	Page shows "Welcome, user!"	Text found on page	Pass
6	Test ends	All assertions passed	Test successful	End

💡 Test ends after all assertions pass or fail

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
page_content	""	"Login page loaded"	"Email and Password fields filled"	"Form submitted, processing login"	"Welcome, user!" displayed

Key Moments - 2 Insights

Why do we simulate user actions like filling fields and clicking buttons instead of calling controller methods directly?

Integration tests mimic real user behavior by interacting with the app through the UI, ensuring all parts work together, as shown in steps 2-4 of the execution_table.

What happens if the expected text is not found on the page after login?

The assertion in step 5 fails, causing the test to fail, indicating a problem in the login flow or page rendering.

Visual Quiz - 3 Questions

Look at the execution_table, what is the page content after step 3?

A "Login page loaded"

B "Email and Password fields filled"

C "Form submitted, processing login"

D "Welcome, user!" displayed

💡 Hint

Check the 'Result' column for step 3 in the execution_table.

At which step does the test check if the login was successful?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for the step where the page content is verified for the welcome message.

If the login page fails to load, how would the execution_table change?

A Step 1 result would show an error and test would end early

B Step 5 would fail because welcome text is missing

C Step 4 would not submit the form

D Step 6 would pass anyway

💡 Hint

Consider what happens if the first action (visiting the page) fails.

Concept Snapshot

Integration tests simulate real user actions across multiple parts of a Rails app.
Use Capybara methods like visit, fill_in, click_button.
Check page content with assertions like assert_text.
They ensure different components work together correctly.
Tests pass only if all assertions succeed.

Full Transcript

Integration tests in Rails simulate how a user interacts with the app by visiting pages, filling in forms, clicking buttons, and checking the results on the page. The test example shows a user logging in by visiting the login page, entering email and password, clicking the login button, and then verifying the welcome message appears. Each step changes the page content or state, which the test checks. If any check fails, the test fails, showing where the problem is. This helps ensure the app works correctly as a whole, not just in isolated parts.

Practice

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

1. Step 1: Understand integration test scope

   Integration tests simulate user actions and check multiple parts working together.

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

3. Final Answer:

   To check how different parts of the app work together from a user's perspective -> Option D

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

1. Step 1: Identify the base class for integration tests

   Rails integration tests inherit from ActionDispatch::IntegrationTest.

2. Step 2: Check each option's base class

   Only class UserFlowsTest < ActionDispatch::IntegrationTest inherits from ActionDispatch::IntegrationTest, others are for models or controllers.

3. Final Answer:

   class UserFlowsTest < ActionDispatch::IntegrationTest -> Option B

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

1. Step 1: Understand assert_select usage

   assert_select checks HTML elements and their content in the response body.

2. Step 2: Analyze the parameters "h1" and "Welcome"

   It looks for an <h1> tag with text exactly matching "Welcome".

3. Final Answer:

   That the page contains an <h1> tag with text exactly 'Welcome' -> Option A

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

1. Step 1: Check variable usage in assertion

   The test asserts redirect to user_path(@user), but @user is never set.

2. Step 2: Understand how to get created user

   After post, the created user should be fetched from controller or database, not assumed as @user.

3. Final Answer:

   Using @user without defining or assigning it in the test -> Option C

4. 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: "[e-mail]", 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

1. Step 1: Identify correct HTTP verb for form submission

   Login forms usually submit with POST, so use post with params.

2. Step 2: Check correct assertion after login

   After successful login, user should be redirected to dashboard, so assert_redirected_to dashboard_path is correct.

3. Final Answer:

   post login_path, params: { session: { email: "[e-mail]", password: "secret" } } followed by assert_redirected_to dashboard_path -> Option A

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