Microsoft "TDD"
Microsoft's "TDD recommendations" have stirred things up: Alan Francis is too shocked to comment; Mike Feathers seems saddened; Ron Jeffries is quite grumpy about it; Scott Bellware is puzzled.
Kent Beck told us that his definition of TDD is Test First Programming plus Incremental Design: the Microsoft Recommendation is not TDD, but is it evil? To be honest, it's not far off how I started to Junit way back in '99 and I benefited from that. As a step on the road to TDD, it may not be so bad but as an end in itself it is dangerous: the greatest danger is that the benefits of post-design testing may not be sufficient to keep the coders. It's a small step from interface first programming to test after. Test-after takes you further away from Test Driven and closer to "test when (if) I get round to it" or "test after this release is out of the way".
Another danger to bulk test writing is that some tests may never pass. I once joined a project to discover that the tests were only running at about 75% success; the developer most responsible argued that the failing tests were a reminder of things to be done; his failing tests encouraged other failing tests in a classic example of "Broken Windows". Refactoring, or even adding functionality out of one's own silo, was much more difficult than it needed to be as it was hard to tell if something had been broken.

1 Comments:
Another danger of test afterwards is that you don't notice broken tests that pass when they shouldn't. If you always write a failing test and then make that test pass, you get quick feedback both on the design of your code and on the quality of the tests.
Post a Comment
<< Home