On Jan 11, 2008 8:04 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote: > David Chelimsky: > > > On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote: > > >> One run of by_input_sets!() takes a couple of seconds, so can > >> be tested; one run of decompose!() takes much longer, so to test > >> decompose!() I should stub by_input_sets!() so it returns canned > >> data (right?). > > > 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!(). > > Ah, well pointed. > > > It also sounds like by_input_sets!() has enough independent > > responsibility that it should actually be public. > > It actually started out as a public method and only this > very thread made me consider switching it to private. :) > > > The standard approach here, which is as much a result of OO principles > > as TDD, is to extract a class with the by_input_sets!() exposed as > > a public method. You mock that object in your Decomposition examples > > and then you have public access to by_input_sets!() on the new class. > > Ok, makes sense, thanks – this definitely > made me think about the design. > > What about the general issue of a slow method that is fast enough to be > testable in isolation, but some other method from the same class calls > it so many times that it needs to be stubbed for that method to be > spec'd in a sane manner?
Every case is different. In this case, the method is slow because it calls one other method repeatedly, so the solution we've discussed may make sense. Without seeing the actual code, it's difficult to assess. In other cases there might be other design changes that could be made to not only improve the speed, but clarify intent. HTH, David > > -- Shot > -- > Fail hard. Fail with motherfucking gusto. Succeeding, like flying, > is throwing yourself to the ground and missing. -- Jeff Hodges > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
