“Test-driven development [TDD] is dual-entry bookkeeping to prevent errors in your code.”

I was lucky enough to see Uncle Bob give a presentation on TDD this week.  During his demonstration of the Bowling Game, I noticed he refrained from writing tests for the all the little helper methods he extracted during the course of the test-code-refactor cycle.  In the past, I had a tendency to take these private methods, make them public and write tests against them.  Something never felt right doing it, but it never hurts to have more tests, right?

However, after watching Uncle Bob, I understand why you don’t need to do that: the original method that spawned all the little helper methods is already well-tested.  If there was a defect in the private helper method, the public method will inform you.  Intuitively, I knew that and was beginning to go there.  Uncle Bob just moved that process along faster, so thanks!