http://pastie.org/pastes/661816
hi,
please have a look at my code. Perhaps anybody knows a solution for that
problem.
Is this all of the code, or did you remove some stuff? I copied the
code in a new rails app and the test passed. What versions of rspec &
rspec-rails are you running?
Pat
hi pat,
thats all of the code that will be executed in
categories_controller_spec.rb. the rest is commented out.
i use the newest version of both gems? could that be a bug. which
versions of rpsec and rspec-rails do you use?
alexanders@alexanders-desktop:$ gem list -l rspec
*** LOCAL GEMS ***
rspec (1.2.9, 1.2.8)
rspec-rails (1.2.9, 1.2.7.1)
cheers,
Alexander
On Wed, Oct 21, 2009 at 3:58 AM, Alexander S. [email protected]
wrote:
hi pat,
thats all of the code that will be executed in
categories_controller_spec.rb. the rest is commented out.
Looks like this may be the same issue as the other thread. You didn’t
show all the code, because there’s an unknown UserController 
I’m
going to stop responding in this thread, and focus on the other one,
because I suspect that both problems you’re experiencing have the same
root cause.
Pat
im repeating this message here in the mailing list with an email.
i already answered the message at http://www.ruby-forum.com,
but it seems that delivering messages via
http://www.ruby-forum.com lasts way too long, so i write an email to the
mailing list.
hi pat,
thats all of the code that will be executed in
categories_controller_spec.rb. the rest is commented out.
i use the newest version of both gems? could that be a bug. which
versions of rpsec and rspec-rails do you use?
alexanders@alexanders-desktop:$ gem list -l rspec
*** LOCAL GEMS ***
rspec (1.2.9, 1.2.8)
rspec-rails (1.2.9, 1.2.7.1)
cheers,
Alexander
Pat M. schrieb:
Pat M. wrote:
On Wed, Oct 21, 2009 at 3:58 AM, Alexander S. [email protected]
wrote:hi pat,
thats all of the code that will be executed in
categories_controller_spec.rb. the rest is commented out.Looks like this may be the same issue as the other thread. You didn’t
show all the code, because there’s an unknown UserController
going to stop responding in this thread, and focus on the other one,
because I suspect that both problems you’re experiencing have the same
root cause.Pat
You are completely right! There IS a before_filter in UserController,
which executes this method before every action:
But why does this filter prevents the index action from being executed?
Alexander
On Wed, Oct 21, 2009 at 1:07 PM, Alexander S. [email protected]
wrote:
But why does this filter prevents the index action from being executed?
Because returning ‘false’ from a filter does exactly that: it prevents
the execution of the controller action.
I’ll bet I know what you’re thinking – you’re thinking, “But I
override @login_user in my example group’s before(:each) code!”
Yes, you did. But you didn’t prevent the filter from executing, and
the first line of your logged_in? method sets the value of @login_user
again, even if it was already set. As you have it here, you’ll be
doing that database lookup every single time current_user is called or
an action is called in this controller.
I would suggest changing that first line of the filter from
"@login_user = " to "@login_user ||= " – which sets the value only if
it was previously false or nil. Not only will this make your testing
code work, but it’ll eliminate any lookup redundancy.
–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
Hi Stephan,
thank you very much for this comprehensive answer. And thanks to all
others participating at this thread. This will help me on my further
attempts to write tests with rspec.
Cheers,
Alexander
Stephen E. wrote:
On Wed, Oct 21, 2009 at 1:07 PM, Alexander S. [email protected]
wrote:But why does this filter prevents the index action from being executed?
Because returning ‘false’ from a filter does exactly that: it prevents
the execution of the controller action.I’ll bet I know what you’re thinking – you’re thinking, “But I
override @login_user in my example group’s before(:each) code!”Yes, you did. But you didn’t prevent the filter from executing, and
the first line of your logged_in? method sets the value of @login_user
again, even if it was already set. As you have it here, you’ll be
doing that database lookup every single time current_user is called or
an action is called in this controller.I would suggest changing that first line of the filter from
"@login_user = " to "@login_user ||= " – which sets the value only if
it was previously false or nil. Not only will this make your testing
code work, but it’ll eliminate any lookup redundancy.–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org