Test Driven Design

Test Driven Development or TDD, from the Agile Alliance:

 

“Test-driven development” refers to a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).

It can be succinctly described by the following set of rules:

 

1. write a “single” unit test describing an aspect of the program
2. run the test, which should fail because the program lacks that feature
3. write “just enough” code, the simplest possible, to make the test pass
4. “refactor” the code until it conforms to the simplicity criteria
5. repeat, “accumulating” unit tests over time”

Link

 

The above are needed within Software Engineering Practices, but in reality, it maybe difficult to embed testing into the development process for a number of reasons:

1-The Agile team does not have a Test SME

2-Automated Test cases do not exist for the current project and have to be built

3-There is a lack of tooling and test licenses

4-There is no central Testing SME group

5-Time, budget constraints

6-No Testing Strategy or Entry-Exit criteria

In spite of these restrictions, Test Driven Development is very important to enable software engineering best practices. TDD is akin to how a car is built and tested along each station within a manufacturing line. If there is a defect at any station, the entire line is stopped until the problem is resolved. This early testing and remediation is a central component of improved vehicle quality and dependability.

 

The license costs (there are also open source alternatives within the Apache project and other open source consortiums); training costs; and environmental maintenance (test cases, tooling, underlying infrastructure) is paid off handsomely in reduced errors, an increase in output velocity, quality and dependability.

 

TDD is a natural part of an Agile process, with smaller codebases being produced in an iterative model. Given the constant improvement or addition of code, TDD will be necessary to quality check the code branch updates to the central code repository. This includes unit tests and component tests which wil use both automated and manual test cases. TDD does not mean that everything is automated. In reality, you will still need to do manual testing and sanity checks.

 

Using TDD early on in the development process will help elucidate the design and requirements. Often, test cases are a good start for a new developer on a project, to understand the requirements and parameters of the scope. This will help in building proper modules and components leading to cleaner, focused classes, looser coupling, and documented, relevant interfaces (eg REST APIs).

 

Within the Agile process, using TDD will allow us to extend or amend a current system to changing business requirements and demonstrate to the end-user that reliability, security and dependability are baked into the product from the beginning of the project.

ROI

TDD is usually a long-term investment with benefits. The Costs and Benefit metrics are given below, you will need to track both, and justify the investment.

Costs	Benefits
License fees	Increased output velocity, reduced time
Training	Reduced errors
Agile necessitates organisational changes and related costs eg a Test SME needs to be on the project from the beginning	More reliable products
Complexity – integrated TDD product including SaaS is not simple and carries networking costs and related operational costs	Fewer production issues and roll-backs
Does not support legacy code bases very well	Forces an upgrade to better code bases, components and frameworks, which reduce security risks as well as improving productivity