Test-First Development - A Brief Definition

Test-first development is an approach to code software systems. More than that, it's the approach I use in my daily coding work and that I advocate in this tutorial. Test-first is much more than a quality-assurance activity; it drives the software design towards easy testing and simplicity. That's why test-first development is also called test-driven development or even test-driven design [Beck02]. The following points describe the most important aspects of the test-first approach.

Before writing a line of production code, you first build an automated-failing test, which motivates this code.
You write only as much production code as required for the test to arrive at working code as fast as you can.
As soon as the code works, you refactor it in order to make it as clean as possible, which basically means to remove all duplication.
The development progresses in small steps, where testing and coding alternate. Such a "micro-iteration" does not take more than 10 minutes.
When you integrate production code into the overall system, all unit tests have to run successfully.

This small set of rules may appear arbitrary to some programmers and contradict their personal experiences. Kent Beck [02] does an excellent job at showing the obvious and not so obvious reasons why test-driven development is a sound idea. The goal of this tutorial is to show how test-driven development looks in practice and to convince you that it actually works. Some of its benefits are obvious.

Each single piece of code gets tested. This means changes that could destroy existing functionality are discovered immediately. It plays a decisive role, particularly at the time of software integration, and thus serves as a form of continuous regression testing.
The tests document the code because, in the ideal case, they show both the normal use and the expected reaction in case of errors.
The micro-iterations are very short, which means very quick feedback. Within 10 minutes at most, you cannot program a lot, so you cannot make many mistakes.
The design of a program is essentially determined by the tests (see also the subsection, Evolutionary design, in ). In many cases, this leads to simpler design as compared to one devised on the drawing board, because it is hard to write simple tests for complex structures. This is the reason why many consider test-driven development to be much more of a design approach than a testing approach [URL:WikiTFD].

Don't get me wrong, though: test-driven coding can be difficult and trying; it is no silver bullet either. That's why another goal of this tutorial is to show typical test-first problems and to explain when it is acceptable or even necessary to depart from the rules.

Many experienced and successful software developers who have been engaged mainly in design-first programming during their professional careers are sceptical about the idea of a design that develops gradually in small steps. All these skeptics are encouraged to temporarily forget about their doubts, experiment with the approach (for not too short) a while, and then judge. For one phenomenon can only be experienced when you try it yourself: in contrast to subsequent testing, creating test cases before the app code is really fun!