On Jan 11, 2008 11:40 AM, Zach Dennis <[EMAIL PROTECTED]> 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.
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 :) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
