rspec users - May 2007 - Stubbing authentication across multiple controllers

Hi,

I''m new to RSpec, so I''m not too sure of the best practises in
stubbing. I was thinking along the lines of including a helper method that would
stub out a users id and posts to sessions/create. It works fine when speccing
SessionsController, but of course it fails when it is included into other
controllers specs, because of the post. I''ve tried posting to an
absolute path ("http://test.host/sessions/create") and to a relative
path ("/sessions/create"), but that doesn''t seem to work
either.

Perhaps I''m going about this the wrong way, so if anyone has any
suggestions it would be appreciated.


#Helper method that is included in controller specs
def login_as(username, password = "foo", id = "1")
  user = mock(username)
  user.stub!(:id).and_return(id)
  user.stub!(:to_param).and_return(id)
  User.should_receive(:authenticate).with(username, password).and_return(true)

  #Here it fails if included in a controller that isn''t
SessionController
  post(:create, :login => username, :password => password)

  puts response.inspect

  controller.send :current_user=, user
end
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

Blake,

You might consider stubbing your controllers at a higher level.  
Presumably session/create sets up something in the session which your 
other controllers check to see if you are logged in.  If you have your 
controllers call some method to make the check you can stub that; so far 
as they are concerned it will be as if your user had logged in, but you 
need not actually call SessionController.  For example:

    controller.stub!(:logged_in?).and_return(true)
    controller.stub!(:authorized?).and_return(true)

or even

    controller.stub!(:login_before_acting).and_return(true)   # 
before_filter :login_before_acting

though you can''t use that to spec the authorization code in your 
controller (''cos it will skip the call to #authorized? which 
#login_before_acting would normally make).

Leave your detailed spec as it is for SessionController, but abstract 
the functionality out - and stub it - for everyone else.  It''s your 
choice as to where you place the stubs; personally I make the controller 
call the before_filter but return immediately by stubbing #logged_in?  
and #authorized? as above.  This means I can run specs to ensure my 
controllers do the right thing if the user is not logged in (the stub 
returns false) and/or is not authorized(*).  You may also need to stub 
methods to return the current_user (etc) as required.  Put them in 
helper methods as you are doing and use in setup/before blocks as 
required.  YMMV.

Best wishes,
  Jerry

(*) There''s a whole other discussion about this - surely if
I''ve spec''d
my authentication code all I need do is check my controller includes the 
module and calls the filter... but somehow I like to see the individual 
specs run for all my controllers...There is NO One True Way in rspec, 
all approaches are equal, but some are more equal than others.  Now I''m
rambling :-).

> Leave your detailed spec as it is for SessionController, but abstract
> the functionality out - and stub it - for everyone else. It''s your
> choice as to where you place the stubs; personally I make the controller
> call the before_filter but return immediately by stubbing #logged_in?
> and #authorized? as above. This means I can run specs to ensure my
> controllers do the right thing if the user is not logged in (the stub
> returns false) and/or is not authorized(*). You may also need to stub
> methods to return the current_user (etc) as required. Put them in
> helper methods as you are doing and use in setup/before blocks as
> required. YMMV.
>
> Best wishes,
> Jerry
That does indeed sound like the best solution. Thanks!

Regards,
Blake

_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE