Introduction

With Test Driven Development (TDD) you do detailed design in a just-in-time (JIT) manner via writing a single test before writing just enough production code to fulfill that test. When you have new functionality to add to your system, perform the following steps:

1. Quickly add a developer test. You need just enough implementation code to fail.  For example, a new method about to be added to a class could be created that just throws a fatal exception.
2. Run your tests. You will typically run the complete test suite, although for sake of speed you may decide to run only a subset. The goal is to ensure that the new test does in fact fail.
3. Update your production code. The goal is to add just enough functionality so that the code passes the new test. 
4. Run your test suite again. If the tests fail you need to update your functional code and retest. Once the tests pass, start over.

Why TDD?

A significant advantage of TDD is that it enables you to take small steps when writing software, which is not only safer it is also far more productive than writing code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written five new lines of code than fifty lines. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

There are other common testing strategies (listed here in order of effectiveness).

1. Write several tests first. This is a variant of TDD where you write more than one test before writing just enough production code to fulfill those tests. The advantage is that you don't need to build your system as often, potentially saving time. It has the disadvantage that you will write more production code at once, increasing the difficulty of finding the cause of new bugs.
2. Test after the fact. With this approach you write some production code then you write enough testing code to validate it. This has the advantage that you're at least still validating the code but has the disadvantage that you lose the design benefit inherent in writing the testing code first.

An underlying assumption of TFD is that a unit-testing framework is available. Agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit, although commercial tools are also viable options.