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. -- 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
pgpcttzu2dmNo.pgp
Description: PGP signature
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
