When TDD Goes Bad #1.1
OK, so people don't seem to get what I was trying to say in my previous TDD post, to the point of claiming (on certain newsgroups) that I "don't get TDD". There were two points I was trying to make. So, I'll try and lay out the first of these now, in a simpler manner:
- Every test you write has a cost associated with it - the development time/cost: C
- Every test you write has a value associated with it - the time/money it'll save over the lifetime of the system: V
- At its simplest level, V must be greater than or equal to C for it to have been worth implementing the test (I'll probably post something separately on the mathematical modelling of this in the future)
The reason that V isn't always greater than C can arise from several situations from a "story" (business) perspective:
- Developers have been provided with open ended requirements - where there is no bounding to the tests that have to be written. At its most extreme case, this could be something like "Test: An unexpected physical occurence takes place outside the system. Result: The data will be backed up correctly". That's an open ended test, though. What if someone cuts power? Or a lightning bolt hits the server rack? Or a tiny blackhole forms over the CPU? "C" would become infinite if all scenarios were dealt with (just because I've used an extreme example here doesn't mean it couldn't be something much more subtle, either). Some of these scenarios are more likely than others, and there's diminishing return on each test being implemented as the likelihood of the scenario occuring drops. To stop this situation from occuring, requirements need to be closed and finite. If they're not closed/finite, you arrive at the situation in my previous post where a developer can simply "judge" how much testing is enough. Unless developers are they calculating the C:V ratio of each test in a situation with any open-endedness, then TDD can go bad.
- Developers have been provided with requirements with negative value - where the cost of implementing the test + code is inherently greater than the value it will deliver. Accurate estimation of tasks and comparison against the value of any given story will avoid this situation.
[In part #1.2, I'll discuss the second part of this]