[rspec-users] specs on private methods

David Chelimsky dchelimsky at gmail.com
Fri Jan 11 12:42:18 EST 2008


On Jan 11, 2008 11:40 AM, Zach Dennis <zach.dennis at gmail.com> wrote:
> On Jan 11, 2008 11:56 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Jan 11, 2008 9:54 AM, Ben Mabey <ben at benmabey.com> 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.

Cool. That sounds like the right way to go. I guess I've just been
lazy - not wanting to have to stray too much from the code generated
by restful_authentication on each project. Guess it's time for my own
internal plugin/engine :)


More information about the rspec-users mailing list