Re:The Pragmatics of TDD
by unclebobmartin on Wednesday March 06, 2013 @09:25PM
(#5335606)
Your edit is one of the reasons. However, writing two or three functions in order to get a test to pass is something I frequently do. The functions are small, and usually have very little implementation at first; but I don't follow the "One Function - One Test" rule.
The rule I follow is: Every line of code you write is to make a failing test pass. If that means writing three new functions, so be it.
I only test public methods. These are often composed of private methods which I might pull out of a method once I get to green and I'm working on readability. A particularly common source of one line methods is to extract query methods(replace a calculated variable with an inline call to the new method). A nice side effect of only testing public methods is that if you find you don't have test coverage on the private methods you know you can delete them(because the public methods that used to use them have all been deleted).
The funny thing about this is when I read this bullet point I thought, "Bob Martin would disagree with this". His rules for TDD ( http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ) would force that method to be tested whether he wants to or not. Then I scroll down to see who wrote the article... Bob Martin
EDIT: But maybe he meant to emphasize "indirectly". Maybe it was under test at first but then got extracted into a simple method under refactoring.