Bird
Raised Fist0
Ruby on Railsframework~10 mins

Controller tests in Ruby on Rails - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to send a GET request to the index action in a Rails controller test.

Ruby on Rails
get [1]
Drag options to blanks, or click blank then click option'
Ausers_url
Bshow_url
Cedit_url
Dnew_url
Attempts:
3 left
💡 Hint
Common Mistakes
Using show_url instead of users_url
Using post instead of get
Forgetting to call the URL helper
2fill in blank
medium

Complete the code to check that the response was successful in a Rails controller test.

Ruby on Rails
assert_response [1]
Drag options to blanks, or click blank then click option'
A:success
B:redirect
C:error
D:missing
Attempts:
3 left
💡 Hint
Common Mistakes
Using :redirect when expecting success
Using :error which means failure
Using :missing which means 404 not found
3fill in blank
hard

Fix the error in the test code to correctly check that a new record was created after a POST request.

Ruby on Rails
assert_difference('[1].count', 1) do
  post users_url, params: { user: { name: 'Alice' } }
end
Drag options to blanks, or click blank then click option'
Auser
Busers
CUsers
DUser
Attempts:
3 left
💡 Hint
Common Mistakes
Using lowercase or plural names for the model
Using variable names instead of class names
4fill in blank
hard

Fill both blanks to test that the show action renders successfully for a given user.

Ruby on Rails
get [1]([2])
assert_response :success
Drag options to blanks, or click blank then click option'
Auser_url
Buser
Cpost_url
Dpost
Attempts:
3 left
💡 Hint
Common Mistakes
Using post_url instead of user_url
Passing the model class instead of an instance
5fill in blank
hard

Fill all three blanks to test updating a user's name and checking the redirect.

Ruby on Rails
patch [1], params: { id: [2].id, user: { name: 'Bob' } }
assert_redirected_to [3]
Drag options to blanks, or click blank then click option'
Auser_url(user)
Buser
C:user
Dusers_url
Attempts:
3 left
💡 Hint
Common Mistakes
Using users_url instead of user_url(user)
Using symbol instead of URL helper for redirect
Passing class instead of instance for id

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

  1. Step 1: Understand controller test role

    Controller tests simulate web requests to check if the controller responds correctly.
  2. 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.
  3. Final Answer:

    To check if web requests respond correctly and perform expected actions -> Option A
  4. 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

  1. Step 1: Recall Rails controller test syntax

    In Rails controller tests, the correct way to simulate a GET request is using get :action_name.
  2. Step 2: Analyze options

    get :index uses get :index, which is correct syntax. Others are invalid or incorrect Ruby syntax.
  3. Final Answer:

    get :index -> Option D
  4. 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
  • Omitting colon before action name
  • Using parentheses incorrectly
3. Given this controller test snippet:
get :show, params: { id: 1 }
assert_response :success
assert_not_nil assigns(:user)

What does assert_not_nil assigns(:user) check?
medium
A. That the @user variable was assigned in the controller
B. That the user with id 1 exists in the database
C. That the response body contains the word 'user'
D. That the controller redirected to the user page

Solution

  1. Step 1: Understand assigns method in controller tests

    The assigns(:user) method accesses the instance variable @user set by the controller.
  2. Step 2: Interpret assert_not_nil usage

    assert_not_nil assigns(:user) checks that @user is not nil, meaning it was assigned.
  3. Final Answer:

    That the @user variable was assigned in the controller -> Option A
  4. Quick Check:

    assigns(:user) checks @user variable = B [OK]
Hint: assigns(:var) checks controller instance variable @var [OK]
Common Mistakes:
  • Thinking assigns checks database existence
  • Confusing assigns with response content
  • Assuming assigns checks redirects
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

  1. Step 1: Check syntax for post request with parameters

    In Rails 5+, parameters must be wrapped inside params: keyword.
  2. Step 2: Analyze given code

    The code uses post :create, user: { name: 'Alice' } missing params:, causing syntax error.
  3. Final Answer:

    Missing params: keyword before user hash in post request -> Option C
  4. 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

  1. 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.
  2. 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.
  3. 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.
  4. Final Answer:

    post :create, params: { user: { name: 'Bob' } } assert_redirected_to user_path(assigns(:user)) assert_equal 'User created!', flash[:notice] -> Option B
  5. 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 unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard