We pass the required items in as method arguments. In the spirit of
sharing code and getting people to review code. Here is our current
LoginManager:
class LoginManager
include Injection
inject :invitation_manager
def login_from_cookie(cookies, session)
CookieLoginManager.new(
:cookies => cookies,
:session => session,
:invitation_manager => @invitation_manager
).login
end
def login_from_session(session)
SessionLoginManager.new(
:session => session,
:invitation_manager => @invitation_manager
).login
end
def login_with_credentials(options, session, cookies)
UserCredentialsLoginManager.new(
:options => options,
:session => session,
:cookies => cookies,
:invitation_manager => @invitation_manager
).login
end
def login_from_password_reset(user, session)
PasswordResetLoginManager.new(
:user => user,
:session => session
).login
end
def login_from_signup(user, session)
SignupLoginManager.new(
:user => user,
:session => session,
:invitation_manager => @invitation_manager
).login
end
end
The reason we did this in the first place was that we needed to be
able to add functionality (accepting invitations) to the login process
and it seemed to get ugly without having it isolated in it's own
object. We use additional login managers behind the scenes to have
simple testable objects for each type of login we do.
The "Injection" module just lets us pull out existing objects from a
global app content and assign them as instance variables. That is how
we are getting reference to invitation manager.
Zach
On Jan 11, 2008 12:45 PM, Ben Mabey <[EMAIL PROTECTED]> wrote:
>
> Zach Dennis wrote:
> > On Jan 11, 2008 11:56 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> >
> >> On Jan 11, 2008 9:54 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> >>
> >>> David Chelimsky wrote:
> >>>
> >>>> In TDD there is a rule of thumb that says don't stub a method in the
> >>>> same class as the method you're testing. The risk is that as the real
> >>>> implementation of by_input_sets!() changes over time, it has access to
> >>>> internal state that could impact the behaviour of decompose!().
> >>>>
> >>>>
> >>> So, stubbing a current_user method on a rails controller would be
> >>> considered bad practice?
> >>> I suppose stubbing the find on User would be just as easy but I have
> >>> always just stubbed controller.current_user.
> >>>
> >> Rails is tricky. These rules are stem from situations in which you are
> >> in complete control of the design. Clearly, Rails makes it easy to
> >> work with if you follow its conventions, but the resulting design is
> >> far from Object Oriented. This is not an inherently bad thing - don't
> >> get me wrong. I use Rails and it's a delight in terms of development.
> >> But it's a challenge in terms of this kind of testing.
> >>
> >> That said, the User class object is a different object than a user
> >> instance, so I have no issue w/ stubbing find on it.
> >>
> >> As for controller.current_user, a purist TDD view would have you move
> >> that behaviour elsewhere. I break the rule and just stub it directly.
> >> This general advice I learned from Uncle Bob Martin: sometimes you
> >> have to break the rules, but when you do you should do it consciously
> >> and feel dirty about it ;)
> >>
> >
> > On the current project we've quit moved all authentication into a
> > LoginManager. This has worked out so nicely as we have simple methods
> > for: login_from_cookie, login_from_session,
> > login_from_user_credentials, etc.
> >
> > This cleans up a lot of the hairy code sprinkled throughout
> > controllers and before filters which were trying to do some form of
> > authentication based on peeking at the sessions themselves or
> > validating users.
> >
> >
> Interesting, do you pass in the session in the constructor or how do you
> get access to the session data?
>
> -Ben
>
--
Zach Dennis
http://www.continuousthinking.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
