Re: depot test-driven development exercise


#1

-------------- Original message ----------------------
From: removed_email_address@domain.invalid

Also, why did the book want to test “assert_template ‘search/
results’”? That seems like an error to me. The default view for a
controller’s method (action) has the same name as the action, right?
Unless you do a “redirect_to :action => ‘results’” in which case the
“assert_response :success” would now fail because we are redirecting
to a page with a different name. This really confused me and caused
me to flail around much longer than necessary to solve this problem.

Or is the test correct and I can have an action named “search”
rendered by a view named “results”?
Bingo.

It is essential to understand the difference between redirect_to :action
=> ‘results’ and render :action => ‘results’.

The former doesn’t run any of your rhtml files. Instead it returns a
“302 Moved” status to the client (rather than the typical 200 OK
followed by an HTML page). The web browser sees this, and interprets it
as a directive to make another request against the server – this time
for the /search/results URL. It’s an entirely separate request, so it
goes through the whole Routing -> Controller -> View thing all over
again. That also means all the instance variables you set up in the
action that issued the redirect aren’t available in the second
request.

The latter (render) just tells Rails to run a different rhtml page to
determine what content to send back. It’s all the same request, and it’s
just an internal Rails pipeline switcheroo, so the browser has no idea
that any of it happened.

Devin