On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote: > Daniel Tenner: > > > Might be a personal thing, but my approach is that I try to test the > > public behaviour of the object. Testing private methods is, imho, > > getting dangerously close to specifying how the object does its > > business, rather than what it does. > > I agree on principle, but I ran into the following case in my PhD: > > There's a Decomposition class that decomposes an FSM to a given > architecture. Its public methods should be new() and decompose!(). > Now, decompose!() works by running a private method by_input_sets!() > many times with different parameters. > > 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 this situation, I think I do need to test/spec the by_input_sets!() > private method – otherwise there would be no code that would check on > the way it works.
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!(). It also sounds like by_input_sets!() has enough independent responsibility that it should actually be public. 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. Cheers, David > > -- Shot > -- > A school in the UK is using RFID chips in school uniforms to track > attendance. So now it's easy to cut class; just ask someone to carry > your shirt around the building while you're elsewhere. -- Bruce Schneier > > _______________________________________________ > 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
