In TDD, the tests are a means to an end -- the end being code in which we have great confidence. If our knowledge of the implementation gives us confidence even without a test, then we will not write that test.
This is, I think, an important piece of the design effort; we need to recognize where the parts of the system are where testing will have unacceptable ROI, and build into our designs the constraint that these parts of the system must be expressed using code that is "so simple there are obviously no deficiencies".
It's the complicated parts of the code (Conditionals, Loops, Operations, Polymorphism) where we need the testability constraint, and a test first approach is an acceptable mechanism for fixing that constraint.
If we see parts of the system that could be dramatically simplified but that don't demand change at the moment, then we will leave them alone.
Adam Tornhill's work suggests that we should be using the source control system to identify hotspots. If TDD is going to make a difference, it has to be at the points where the infelicities of the previous design have real impact on daily work.
TDD helps you to pay attention to the right issues at the right time so you can make your designs cleaner, you can refine your designs as you learn.... What's naive is assuming that clean code is all there is to success.
The Chrysler project was cancelled; as far as I can tell LifeWare is still around.
Mike Hill points out that for the past 25 or whatever years, the software development business has been over provisioned in money, compute, and resources. If that gets squeezed back down to "normal" levels, then design practices may become much more significant to long term success.
No comments:
Post a Comment