program selection system

Often it is suggested that Test Driven Development has moved into the mainstream and that not applying a test first approach is exceptional. Having worked with TDD for the last five years I have observed that far from being ubiquitous, effective application of TDD is uncommon. This session takes a pragmatic approach in evaluating the implementation of, impediments against and measurable benefits of TDD on a commercially successful project. Analysis of this experience will show how and why TDD is being used incorrectly and how this situation can be corrected.

Specifically the session will concentrate on real word examples from the projects in question in the areas of:

The approach taken in the introduction of TDD.

• How the intent to use TDD was communicated.
• The degree of freedom developers were allowed in their application of the technique.
• The measurement of the application of the technique.
• A brief description of the technical mechanics employed (use with Ajax, Mocks and Spring etc.).

Impediments to and pitfalls during TDD adoption.

• After initial enthusiasm competent developers can come to resent TDD as they perceive it as being a technique which reduces their development velocity. This is especially true when burndown charts and measurement of velocity are introduced at the same time as TDD.
• Dogmatic application, especially common to new practitioner, leads to increased costs without corresponding return on investment.
• TDD is a technique that is easy to communicate, easy to execute in a workshop environment but surprisingly difficult to master on a live project.
• Along with other agile techniques, TDD produces empirical evidence which can be used to measure code quality and progress. As with all statistics care has to be taken in the naive interpretation of results. The bar is be green, the coverage high and the acceptance tests passing. This is a good sign but not an absolute guarantee of success that outweighs any other indication. It can be politically difficult to correct the misplaced enthusiasm of others after a period of TDD evangelising.
• Although well understood in the agile community the real implications to the cost profile of a project are little understood and often hesitantly communicated to the stakeholders. It is well documented that initial development costs more but there is also an increased cost in making maintenance code updates to the developer. In theory there is a reduction in cost in testing, bug fixes and rework but measurements of these activities is more difficult and often overlooked.

The measurable benefits

• As practitioners gain experience their code quality increases. Classes become more cohesive and less tightly coupled.
• Driving development top down from the acceptance tests encourages developers to apply the YAGNI principle. They are much less likely to build that extra piece of cool code which turns out to be of limited benefit in meeting the user goal.
• Solutions architects and business stakeholders quickly grasp that tests increase confidence of the functional correctness of a given area. This makes them more confident in their support of other agile techniques such as refactoring. This introduces a virtuous circle where code can be cut faster because developers know that thy will be able to go back and optimise or add features later with management approval. It also means that the code base stays dynamic and is less likely to be the subject of arbitrary and all encompassing code freezes dictated by senior managers attempting to reduce risk of instability.
• TDD can be pushed the right to the beginning of the development process. Acceptance tests are created at the same time as the use cases (in some cases these acceptance tests became the definitive source of the use case definition). This focuses the analysts on what the reality of their requirements and gives a concrete measure of progress.