Zach Dennis 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.
>>Interesting, do you pass in the session in the constructor or how do you
get access to the session data?
-Ben