A better case for TDD
Standard Bank elected to drive the adoption of Test Driven Development (TDD) in the multi-channel portfolio. Despite a concerted effort to embed TDD into the engineering practices adoption has ,unfortunately, been low. It became evident that one of the main reasons holding developers back from making the paradigm shift was that in the various TDD workshops and coaching sessions too much emphasis was being placed on the tests themselves. The value of a test first approach over a test after approach was not properly understood. We never really got to the heart of what TDD is really all about.
Agile Principle and Value alignment with TDD Practice
As a Technical Lead I encourage my engineers to continuously evaluate their processes and practices against our core set of values and principles. Teams that have adopted Agile methods have implicitly agreed to the values and principles described in the Agile Manifesto . These provide the framework which guide the processes and practices that are adopted to deliver value to customers.
TDD is a practical realization of a number of the core Agile principles.
The three simple rules of TDD are: [UncleBob: 01]
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
These rules drive the TDD practices which align with the principles and values as follows:
“Simplicity — the art of maximizing the amount
of work not done — is essential”. [AgileManifesto: 01]
You could draw correlation between TDD and some of the other 12 principles but I think this one best drives home the point. TDD enforces a minimal amount of tests and minimal implementation to make the test pass. More importantly a simple implementation is a realization of a simple design. The Test/Develop/Refactor cycle creates a framework for incremental design and development. It also allows for emergent design; which is perhaps the most important outcomes of TDD.
“Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software”
Following the TDD cycle of Red — Green — Refactor we are guided into a workflow which encourages us to
- break requirements into smaller deliverable pieces
- implement just enough code to satisfy the requirement
- refactor the implementation to improve the quality.
Research [Larman 2003] has proven that incremental software development leads to a faster time to market. In software development, and more so incremental software development, refactoring is essential as the design of the complete solution emerges as each new increment is developed. High quality automated tests give you the required safety net to refactor software and manage technical debt. To be succesful at incremental software development you can’t leave the development of these automated tests to chance. With the “test first” approach of TDD the creation of the tests is inseperable from the software development process.
What does the TDD acronym really stand for
From the principles mentioned earlier, which drive the adoption of TDD, a common thread emerges, which is that TDD is about design i.e. Incremental or Emergent Design and Just in Time design.
When we position TDD as being more about design than development and tests, a mental framework emerges which allows developers to consider the paradigm shift. If the emphasis remains on the tests; reluctant developers can easily fall into the trap of gaming the system by simply writing the tests after development is complete.
When TDD is positioned as a tool to drive out a simple design and implementation which can safely be extended over time adoption of the proactice becomes more palateable. The fact that we end up with high quality tests at the end of the process is a very beneficial side effect.
References
[UncleBob 01] — TheThreeRulesOfTdd : http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
[AgileManifesto 01] — Principles behind the Agile Manifesto : http://agilemanifesto.org/principles.html
[Larman 2003] — Agile and Iterative Development: A Manager’s Guide, Chp 6. Evidence
