Patrick D. wrote:
Vahagn H. wrote:
flash[:notice] ="Reset code sent to #{user.email}"
else
flash[:notice] ="#{params[:user][:email]} does not exit in the
system."
end
All of that could refactor into a model method that takes an email and
returns a
string:
flash[:notice] = User.forgot_password(params[:user][:email])
The goal of refactoring is not just fatter models. Things like the ‘if’
statement work better in model-land.
Further, the result becomes easier to test!
assert_response :success
assert_template 'account/forgot' #all fine so far
Putting a get and a post into the same test is bad luck. Specifically,
you
should think of the secret @request and @response mock objects as
consumables.
Pretend that each of ‘get’ and ‘post’ would burn them up so you can’t
use them
again.
(I don’t know how true this mental model is; maybe you technically can
reuse
them. But…)
Your get and post do not communicate anything to each other, so they
should run
in two different test cases.
The one testing the get could then use assert_select, or assert_xpath,
to test
for the existence of a form, and the correct fields.
post 'account/forgot'
Next, I thought the line should be
post :forgot
unless you are in an integration test, which I have never been able to
get much
traction from. But if you are in a functional test, then your test suite
bonds
with the correct controller - AccountController - and you don’t need to
redundantly declare it in get, or post, or most other helpers.
evaluating nil.[]">
The top of your test suite is broken. Could you post it?
In Rails 1.x, it should have looked like this:
Raise errors beyond the default web-based presentation
class AccountController; def rescue_action(e) raise e end; end
class AccountControllerTest < Test::Unit::TestCase
def setup
@controller = AccountController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
end
The point is the rescue_action line. It ensures that un-rescued errors
do not go
into a crash page, they cause test faults and go directly into your face
when
you run the tests.
The Rails 2 equivalent is…
class AccountControllerTest < ActionController::TestCase
…where the new TestCase infers the controller class from the name of
the
suite, and then runs all that boilerplate code for you.
Either way, exceptions are supposed to be transmitted into your face,
not into a
page, and if you are using integration tests then I’d really like to
hear how to
get them to transmit errors correctly, too!
Aaaand here’s your answer (with GMane’s net-nanny foiled):
post ‘account/forgot’, :user => {:email =>
‘joeATpublic.gmane.org’}
I figured this out by the judicious use of print statements in my
controller printing out the values of options, options[:user], and
options[:user][:email].
Because you pass a subset of the complete params set into post.
One way to learn them is to write your page, run it in script/server,
run your
form, and inspect the spew from the server’s console. It will include
the
params, using .inspect to write them as a raw Ruby hash.
Hope this helps.
And I hope I didn’t confuse everyone too much…
(-:
–
Phlip
