Developer Tests and Double-entry Book-keeping
One thing we were talking about was how the “record and playback” style API of some mocking frameworks devalues the double-entry book-keeping effect of developer tests, because you end up with almost duplicate code in the test and the method under test.
A neat (non-mocking) example of how the double-entry book-keeping style can be used is a test for square rooting a number…
def self.square_root(number) # clever square root algorithm end
class CleverMathTest < Test::Unit::TestCase
def test_should_calculate_square_root_of_number number = 2.0 number_squared = number ** 2 assert_in_delta number, CleverMath.square_root(number_squared), 0.0001 end
The test says something along the lines of “Think of a number, square it and then use your whizzy new algorithm to square root it – you should end up with something close to the number you first thought of.”
I have been consulting for a number of teams that have adopted Agile Methods, including TDD. One common issue I have found is that developers drop the discipline of TDD in the face of schedule pressure. “We don’t have time to write tests” I hear them say. Before I comment on the absurdity of this attitude, let me draw the parallel. Can you imagine an accounting department dropping dual entry bookkeeping because they’ve got to close the books on time? Even before SARBOX such a decision would be such a huge violation of professional ethics as to be unconscionable. No accountant who respected his profession, or himself, would drop the controls in order to make a date.
It’s great to have some powerful reminders about why developer testing is so valuable.