We all heard IT managers, analysts as well as a few testers and programmers speak about that magic development technology called to boost quality and promote testing by giving the priority to test writing.
Sounding like a good idea to try, test-driven development is criticized by experiences software developers for a number of issues:
- It doesn’t respect your time constraints.
Whenever you have time constraints and managers are pushing as you seem to be lagging behind your deadline, TDD isn’t a helper here. Instead, it robs you of freedom to refactor your code when needed as you are now afraid to break the test and having to spend quite a time to fix it.
- It doesn’t give visible results.
If somebody managed to yield better results with TDD, we still don’t see any convincing evidence. With no scientific statistics proving TDD really works, it is only a theory.
- It doesn’t tell you how to maintain software.
There’s often the need to maintain some older projects by making some enhancements, customizations or bug fixes. But how can you write a test for the thing you don’t how to fix? Or, for example, you can start fixing a bug in one place and then realize the problem was elsewhere and you’ve just wasted time on writing the test. The problem is defect fixes are usually more analytical and don’t have fixing requirements which makes TDD useless in this case.
- It isn’t all multilingual.
- It doesn’t see far.
In its nature, TDD looks just into the immediate amount of work whereas real apps often cross over one another, tending to be more complex or even coupled. To be successful, of course, you need to look at the big picture designing some smaller things, however TDD leads you just a few steps further at a time not letting you see some bigger impacts ahead.
What about your TDD experience?