Developed back in 2003, test driven development (TDD), also known as test design development, creates an evolutionary approach to development centring on test-first implementations in which you write the minimum amount of production code that will allow you to then fulfill that test and carry out refactoring.

Generally, the ultimate goal of test driven development is seen as specification – giving you the chance to think through your requirements before writing functional code. However, others believe its primary goal is to use it in the form of a programming technique with the idea that you are producing clean code which will ultimately work.

In this test driven development guide we take a look at how it compares to traditional testing.

What exactly is test driven development?

The steps involved in test driven development are relatively straightforward. First, you quickly produce a test which should be just sufficient enough to determine whether or not the code will fail.

From there, run further tests – this is normally a full test suite, but in some cases you may decide to simply opt for a subset in an effort to ensure that the test does indeed fail. Following that, update the functional code so that it is now capable of passing the tests: and then run the tests again. The programmer should now be confident that the new code meets and surpasses all of the test requirements but if there is a fail then you will need to update the code and carry out a retest. When the tests have been passed, the next stage is to start again: which may involve refactoring duplications out of the design.

So, in short the test driven development cycle is as follows:

1. Create a test
2. Run tests and see if the new test will fail
3. Write code
4. Run tests
5. Refactor code
6. Repeat

So how does test drive development compare to traditional testing?

Generally speaking, TDD can be seen as a technique used for specification that just happens to have the side effect of ensuring that source code is tested completely. Of course there is more testing to carry out: including investigative testing and pre-production testing, both of which should take place early in the project. So what are the differences and similarities with traditional testing?

• Finding defects | With both forms of testing the aim is to find defects. With TDD, when a defect is found you have made progress because you now need to resolve this problem and you have a measure of success. So, confidence is increased and you can move forward with a feeling of confidence.
• Testing with purpose | As with the Agile model, the idea is to test with purpose and understand why the test is being carried out and the levels that should be tested. One of the side effects of TDD is that 100 per cent test coverage is achieved and every line of code will be tested: this is something that traditional forms of testing cannot guarantee. As such it can be argued that TDD often produces better code testing overall.

What about documentation?

In most cases, programmers prefer not to read the documentation for a system, instead opting to work with the code. So, when they are trying to understand operations they will normally look at the code being used to invoke it. Well-written tests will follow this pattern and so these tests are effectively part of your documentation.

Of course this is unlikely to be enough documentation on its own: you will still need elements such as system overviews, operations and other supporting documentation.

So why should you consider test driven development?

Perhaps the main advantage of TDD is that you can use it to make short steps whenever you are writing software. It should be more productive than writing code in large steps because any errors are easier to find and fix when you are taking things step by step. Effectively, programmers can focus on individual tasks with their ultimate goal being to ensure that the test is passed. Indeed despite the fact that more code will be required with TDD, generally the implementation time should be shorter because the increased number of tests will help to limit the defects within the code.

According to a study in 2005, TDD involves writing an additional number of tests: and this in turn helps programmers to be more productive. Programmers utilizing TDD on greenfield projects state that they rarely use a debugger.

Are there any downsides to test driven development?

Critics of TDD suggest that it does not offer sufficient testing when full functional tests are needed to determine failure or success because of its extensive employment of unit tests.

In addition, management support will be needed. If it is not there then management is likely to feel that time is wasted on carrying out the tests. There is also the risk that some tests will be badly written and therefore prove expensive. Indeed there are not flexible modules that are able to accept new requirements without the need to change tests. As such, testing for extreme conditions can often be easier than an overly detailed test.

So overall, is TDD worth your time?

TDD is being adopted quickly by developers of agile software for the development of source code; and is even being used within the frame of database development.

It should not be seen as a replacement for traditional testing: but should instead be seen as a way of defining a proven and efficient method of unit testing. The side effect is that the tests then become working examples for the code and offer a working specification that can be used for the code. As such, TDD should work fantastically well and if you’re not currently using it then, as a software developer, it is definitely something you should put under serious consideration.