Integration tests in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this Rails integration test?

Consider this integration test that simulates a user logging in and visiting the dashboard page. What will the test assert about the response?

Ruby on Rails

require "test_helper"

class UserFlowsTest < ActionDispatch::IntegrationTest
  test "login and visit dashboard" do
    post login_path, params: { session: { email: "[e-mail]", password: "password" } }
    follow_redirect!
    get dashboard_path
    assert_response :success
    assert_select "h1", "Dashboard"
  end
end

A The test will fail because follow_redirect! is called before get dashboard_path.

B The test will fail because assert_select cannot be used in integration tests.

C The test will raise an error because post login_path requires a CSRF token.

D The test will pass if the dashboard page loads with an <h1> containing 'Dashboard'.

💡 Hint

Remember that follow_redirect! follows the redirect after login, and assert_select works in integration tests.

The test simulates a login by posting credentials, follows the redirect to the logged-in page, then requests the dashboard page. It asserts the response is successful and that the page contains an

with 'Dashboard'. This is valid and will pass if the app behaves correctly.

❓ state_output

intermediate

What is the value of session[:user_id] after this integration test runs?

In this integration test, a user logs in. What will be the value of session[:user_id] after the post request?

Ruby on Rails

post login_path, params: { session: { email: "[e-mail]", password: "password" } }

# What is session[:user_id] now?

A It will be the id of the logged-in user (an integer).

B It will be nil because session is not accessible in integration tests.

C It will be a string containing the user's email.

D It will raise an error because session is private in integration tests.

💡 Hint

Think about how integration tests simulate requests and what is accessible.

In Rails integration tests, the session hash is not directly accessible after requests. You cannot read session[:user_id] directly in the test. Instead, you verify behavior through responses or database state.

🔧 Debug

advanced

Why does this integration test fail with a 'No route matches' error?

This integration test tries to visit a profile page but fails with a routing error. What is the cause?

Ruby on Rails

get profile_path(user_id: 1)
assert_response :success

A The routes file does not define a profile_path route.

B The test forgot to log in the user before accessing the profile page.

C The route helper profile_path requires a user object, not a user_id parameter.

D The get method requires params to be passed as a separate hash, not inside the path helper.

💡 Hint

Check your config/routes.rb for the profile_path definition.

The error indicates no route matches the given path. This usually means the route is not defined in routes.rb. Passing parameters incorrectly or login state issues cause different errors.

📝 Syntax

advanced

Which option correctly writes an integration test to check a redirect after logout?

You want to test that after logout, the user is redirected to the home page. Which code snippet is correct?

A

delete logout_path
follow_redirect!
assert_response :success
assert_select "h1", "Home"

B

delete logout_path
assert_redirected_to root_path

C

post logout_path
assert_response :redirect
assert_redirected_to root_path

D

get logout_path
assert_response :success
assert_select "h1", "Home"

💡 Hint

Remember logout is usually a DELETE request and you must follow redirects to check final page content.

Option A correctly sends a DELETE request to logout_path, follows the redirect, checks the response is success, and verifies the home page heading. Other options use wrong HTTP verbs or miss following redirects.

🧠 Conceptual

expert

What is the main difference between Rails integration tests and controller tests regarding session and cookies?

Choose the statement that best describes how session and cookies behave differently in Rails integration tests compared to controller tests.

A Integration tests require manual management of session and cookies, while controller tests automatically handle them.

B Both integration and controller tests provide direct access to session and cookies after each request.

C Integration tests simulate multiple requests and do not expose session or cookies directly, while controller tests allow direct access to session and cookies.

D Controller tests simulate full browser behavior including cookies, but integration tests do not.

💡 Hint

Think about the scope and purpose of integration vs controller tests.

Integration tests simulate user behavior across multiple requests and do not expose session or cookies directly to tests. Controller tests focus on single controller actions and allow direct access to session and cookies for easier unit testing.

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