Overview:

This concept describes a technique to bring test design chronologically in-line with software design.

Main Description:

In test-first design, the developer first writes a small portion of a developer test, and then writes just enough implementation code to make that developer test compile and execute. Then they write a little bit more of the test and then add enough code to make that new bit compile and pass. This cycle can last somewhere between 30 seconds and five minutes.

Rarely does it grow to ten minutes. In each cycle, the tests come first. Once a unit test is done, the developer goes on to the next test until there are no more tests to be written for the implementation of the work item currently under development.

The practice of test-first design changes how the developer thinks. Tests are not written as an afterthought. Instead, developer tests are written as part of the everyday, every minute way of building software.

What are the advantages of test-first design?

1. Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an examination must be made of the behavior of each piece of code to be written, correct and incorrect behaviors must be defined. In a way, writing the tests before the code can be considered a version of detailed design.
2. Code units designed for testability up front are cleaner and more loosely coupled.
3. Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins when it could be more tempting to move ahead based on assumptions.
4. A clearer collaboration strategy between the developer and others that might be responsible for the requirements, architecture, and design is put in place. During the creation of the tests, there must be a meeting of the minds as to what has been specified. After that, the implementation can carry on with confidence that there is a shared vision of what the code should do.
5. There are unambiguous criteria for completion of the code. When the tests pass, the code is working as specified. Non-functional quality dimensions can be dealt with separately, but there is a clear moment when the code behaves correctly.
6. The technique drives the developer to work in smaller increments with faster quality feedback. At any time the developer is just one test away from having error-free code.
7. There is a separation of concerns and effort between getting code working and improving the quality of the code that already runs correctly. Separating out these two areas of concern provides focus and time management support to a developer who in one pass over the implementation makes it pass the tests as simply as possible and then in a subsequent pass, looks for areas to improve.

Guideline:
With Test-First Design (TFD) 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 they tests fail you need to update your functional code and retest. Once the tests pass, start over.

Why TFD:
A significant advantage of TFD 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 other common testing strategies (listed here in order of effectiveness).

1. Write several tests first. This is a variant of TFD 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.

Good Things to Know:

1. 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.
2. Test-Driven Design (TDD) = TFD + Refactoring
3. TFD/TDD is commonly used with object-oriented business code, although this approach can be taken with procedural code, user-interface code, and database code.