Developer Tests and Double-entry Book-keeping

Last night I came across this recording of Kent Beck giving an excellent talk about developer testing and accountability which reminded me of a couple of things we’d been talking about at work.

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…

class CleverMath

  def self.square_root(number)
    # clever square root algorithm
  end

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

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.”

Uncle Bob has a great article about the analogy between developer testing and double-entry book-keeping…

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.