What is the main purpose of controller tests in Rails?
Controller tests check if the controller actions respond correctly to requests, render the right views, and handle data properly.
Click to reveal answer
beginner
Which HTTP methods are commonly tested in Rails controller tests?
GET, POST, PATCH/PUT, and DELETE are the common HTTP methods tested to simulate user actions on resources.
Click to reveal answer
beginner
In Rails controller tests, what does the 'get :index' command do?
It simulates a GET request to the 'index' action of the controller, allowing you to test the response and assigned variables.
Click to reveal answer
intermediate
How do you check if a controller action redirects to another page in Rails tests?
Use 'assert_redirected_to' with the expected path to verify the controller action sends a redirect response.
Click to reveal answer
intermediate
Why is it important to test both successful and unsuccessful controller actions?
Testing both ensures your app handles normal cases and errors gracefully, improving reliability and user experience.
Click to reveal answer
Which method simulates a POST request in Rails controller tests?
Apatch
Bget
Cdelete
Dpost
✗ Incorrect
The 'post' method simulates sending a POST request to a controller action.
What does 'assert_response :success' check in a controller test?
AThe action returns a 200 OK status
BThe action redirects to another page
CThe action raises an error
DThe action renders a JSON response
✗ Incorrect
'assert_response :success' verifies the HTTP status code is 200, meaning the request was successful.
How do you test that a controller action assigns a variable in Rails tests?
Aassert_redirected_to
Bassert_template
Cassigns(:variable_name)
Dassert_equal
✗ Incorrect
'assigns(:variable_name)' lets you check the value assigned to an instance variable in the controller.
Which Rails testing framework is commonly used for controller tests?
AJUnit
BRSpec
CMocha
DJest
✗ Incorrect
RSpec is a popular Ruby testing framework often used for Rails controller tests.
What is the purpose of 'assert_template' in controller tests?
AVerify the rendered view template
BCheck the HTTP status code
CTest database changes
DSimulate a user login
✗ Incorrect
'assert_template' confirms that the controller rendered the expected view template.
Explain how to write a basic controller test for the 'show' action in Rails.
Think about the steps to simulate a request and check the results.
You got /4 concepts.
Describe why testing both success and failure cases in controller actions is important.
Consider what happens when things go right and when they go wrong.
You got /4 concepts.
Practice
(1/5)
1. What is the main purpose of a controller test in Rails?
easy
A. To check if web requests respond correctly and perform expected actions
B. To test database schema changes
C. To verify CSS styles are applied properly
D. To check JavaScript functions run without errors
Solution
Step 1: Understand controller test role
Controller tests simulate web requests to check if the controller responds correctly.
Step 2: Compare options
Only To check if web requests respond correctly and perform expected actions describes checking web requests and expected actions, which is the controller test's purpose.
Final Answer:
To check if web requests respond correctly and perform expected actions -> Option A
Quick Check:
Controller tests check web requests = A [OK]
Hint: Controller tests simulate web requests to check responses [OK]
Common Mistakes:
Confusing controller tests with database or view tests
Thinking controller tests check CSS or JavaScript
Assuming controller tests modify database schema
2. Which of the following is the correct syntax to simulate a GET request to the index action in a Rails controller test?
easy
A. get('/index')
B. get index
C. get index()
D. get :index
Solution
Step 1: Recall Rails controller test syntax
In Rails controller tests, the correct way to simulate a GET request is using get :action_name.
Step 2: Analyze options
get :index uses get :index, which is correct syntax. Others are invalid or incorrect Ruby syntax.
Final Answer:
get :index -> Option D
Quick Check:
Use symbol with get method = C [OK]
Hint: Use get :action_name with a symbol for controller tests [OK]
Common Mistakes:
Using string or method call syntax instead of symbol
4. Identify the error in this Rails controller test code:
post :create, user: { name: 'Alice' }
assert_redirected_to user_path(assigns(:user))
medium
A. assert_redirected_to should be assert_response
B. Using post instead of get for create action
C. Missing params: keyword before user hash in post request
D. assigns(:user) cannot be used in controller tests
Solution
Step 1: Check syntax for post request with parameters
In Rails 5+, parameters must be wrapped inside params: keyword.
Step 2: Analyze given code
The code uses post :create, user: { name: 'Alice' } missing params:, causing syntax error.
Final Answer:
Missing params: keyword before user hash in post request -> Option C
Quick Check:
Use params: for parameters in post requests = A [OK]
Hint: Always use params: keyword for request parameters [OK]
Common Mistakes:
Omitting params: keyword in request methods
Confusing HTTP verbs for actions
Misusing assertion methods
5. You want to test that after creating a new user, the controller redirects to the user's show page and sets a flash notice. Which test code correctly checks both behaviors?
hard
A. post :create, params: { user: { name: 'Bob' } }
assert_response :redirect
assert_nil flash[:notice]
B. post :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert_equal 'User created!', flash[:notice]
C. get :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert flash[:alert] == 'User created!'
D. post :create, user: { name: 'Bob' }
assert_response :success
assert flash[:notice] == 'User created!'
Solution
Step 1: Check HTTP verb and parameters
Creating a user uses POST with params: keyword, so post :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert_equal 'User created!', flash[:notice] is correct here.
Step 2: Verify assertions for redirect and flash
post :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert_equal 'User created!', flash[:notice] asserts redirect to user's show page and flash notice equals 'User created!'. This matches the requirement.
Step 3: Eliminate incorrect options
post :create, user: { name: 'Bob' }
assert_response :success
assert flash[:notice] == 'User created!' misses params: keyword and uses assert_response :success instead of redirect. get :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert flash[:alert] == 'User created!' uses GET instead of POST and wrong flash key. post :create, params: { user: { name: 'Bob' } }
assert_response :redirect
assert_nil flash[:notice] asserts flash[:notice] is nil, which is wrong.
Final Answer:
post :create, params: { user: { name: 'Bob' } }
assert_redirected_to user_path(assigns(:user))
assert_equal 'User created!', flash[:notice] -> Option B
Quick Check:
POST with params, redirect, and flash notice = D [OK]
Hint: Use post with params:, assert_redirected_to, and assert_equal flash [OK]
Common Mistakes:
Using get instead of post for create action
Forgetting params: keyword
Checking wrong flash key or missing redirect assertion
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.