For some time now I have had TDD in "Assess" status. While I am a strong proponent of automation, including tests, I have remained somewhat unconvinced by the arguments for TDD. This has been influenced by the environments I found myself operating in. Either with high degrees of uncertainty assessing technology viability, or, at the other end of the extreme, augmenting a mature system which treats automated tests as very much a secondary concern.
With an orientation towards pragmatism and "getting things done" and having approached TDD somewhat warily, I am now convinced of the value it offers. For me, the main factors have been:
- Predictability & deterministic operations: I have worked on a lot of data-driven applications which have, at times, exhibited unpredictable behaviour. TDD allows me to rapidly experiment with, and verify against, varying data combinations and be confident of the outcome, without having to be connected to a multitude of data sources. This gives me confidence in the behavior of the system and enables me to more easily reason about its correctness and performance.
- Loose coupling: By its very nature, TDD enforces discrete operations, which the hosting application composes and orchestrates, thus reducing complexity. I am in favour of appropriate application of SOLID principles, and it seems to me that TDD encourages this, in a good way. The minimised dependencies and clear interfaces that result enables me to a system that is easier to modify, test, and evolve.
Predictability and evolvability help me to achieve two things:
- Higher quality (which means spending less time finding and fixing defects)
- Faster and simpler enhancement and feature delivery.
If you want to be more confident in the behaviour of your code base and spend more time coding and less time debugging and bug fixing, it's time to adopt TDD.
To learn more, start here: Test Driven Design
Comments
Post a Comment