Traditionally the testing phase usually at the expected end of the software development lifecycle helps improve the quality of an application. It is known that the cost of any requirements or code changes made at this stage of the development cycle is higher. This was illustrated by Barry Boehm’s “Cost of Change” study. Moving the testing phase closer to the start of the development lifecycle can help reduce these costs and at the same time provide more time to test the application. This is what TDD helps as achieve.

One of TDD’s primary principles is writing the tests first. These tests dictate the development of a class or a piece of code. This is a radical shift from the traditional way of having tests written by another group usually separate from the developers involved in writing of the code as a quality assurance process before an application is shipped. Another tenet of TDD is that no code is published without its tests. In fact Martin Fowler argues that TDD lends itself to the refactoring process by providing a way to quickly verify changes.

 

The following are the steps involved in test driven development but. This list does not detail in absolute terms all the processes that have to be followed.

1. Write a test case to test  from a requirements document
   
   • Requirements that tests can be derived from are called testable requirements
   • When collecting requirements testers need to be involved and their task is to verify how the requirement is to tested
2. Run the tests fixing the errors generated by adding the code to satisfy the test
   
   • Each test written should assert only one condition
   • Tests that assert more  than one condition are not good tests
3. Keep writing more tests until there are you cannot think of any more tests to write
   
   • This is a repetition of step number 2 above until all requirements are met

TDD requires the developer to first define the requirement in code as a test then write code to satisfy that requirement. Arguably this is the right way to be looking at requirements since in expressing the requirement in code requires ironing out any ambiguity in its natural language phraseology. The process of removing any ambiguity would usually require the participation of the customer, thus the common customer developer meetings common in an agile development process where TDD got its roots.

Some good test writing skills mentioned in the article include but are not limited to testing only one thing in one test. This helps ease the testing process and certainly makes the tests generated easier to understand and use during the maintenance of an application. Having readymade tests helps maintainers by allowing them to easily verify the integrity of a system after a change by rerunning the tests for a given module or set of modules.

The process of writing tests is not just confined to new development. Maintenance programmers are also encouraged to write tests as they set out to fix any bugs that are in an existing system or as they set out to make enhancements to existing code. Test driven development first came into light from the extreme programming practices that also encourage pair programming among a set of other practices that are aimed at improving the quality of software. May have attributed success of their development efforts to extreme programming and even so test driven development is one of the few practices from extreme programming that many are encouraged to adopt first.
 
Test driven development does improve the quality of the programs that come out of a team. An attribute of a good quality application is one that is easy to maintain. Undoubtedly an application with tests renders itself a good candidate to add updates to and even make changes without worry of the unexpected. The TDD process does require developers to start thinking of requirements a lot more differently than they have traditionally done. This process also brings the testing groups closer to developers. As a result testers can start performing tests on the system early on, allowing them more time to find bugs and having them fixed early in the development phase. Traditional testing practices for example in the waterfall model push testing as the last phase of any development effort. Developers are typically not involved in the testing process and thus developers and testers are far removed from each other. Teams in this set up do not have great relations.