• Implement the Solution
• Implement Developer Tests
• Implementation
• Developer Test

Introdução

Com o Design Teste-Primeiro (TFD) você faz o design detalhado de uma forma just-in-time (JIT) através da escrita de um simples teste antes de escrever bastante código produtivo necessário para executar o teste. Quando você tiver que adicionar uma nova funcionalidade ao seu sistema, execute os seguintes passos:

1. Adicione rapidamente um teste.  Você necessita de código apenas para fazer o erro acontecer. 
2. Execute os seus testes.  Você executará basicamente o procedimento completo de teste, embora por causa da velocidade você pode decidir executar somente um subconjunto. O objetivo é assegurar-se de que o teste falhe de fato. 
3. Atualize o código produzido.  O objetivo é adicionar apenas a funcionalidade necessária para que seu código passe no teste. 
4. Execute seu procedimento de teste de novo. Se os testes falharem é necessário atualizar seu código funcional e testa-lo de novo. Uma vez que os testes passem repita os passos. 

Por Que TFD?

Uma vantagem significativa do TFD é que ele permite executar pequenos passos ao escrever o software, o que não é somente mais seguro como também mais produtivo do que escrever código em grandes quantidades. Por exemplo, suponha que você tenha adicionado um novo código funcional, compilado e testado ele. Existem grandes chances que seus testes falhem por causa de defeitos existentes no novo código. É muito mais fácil encontrar, e então reparar, estes defeitos se você escrever cinco linhas novas de código ao invéz de cinqüenta. A implicação disto é que o quão mais rápidos forem seu compilador e seu procedimento de teste de regressão, mais atrativo será continuar com passos cada vez menores. 

Existem outras três estratégias comuns de teste (em ordem de eficácia).

1. Escrever diversos testes primeiro.  Esta é uma variante do TFD onde você escreve mais de um teste antes de escrever bastante código produtivo necessário para executar os testes. A vantagem é que você não precisa construir seu sistema como normalmente é feito, podendo economizar tempo. Tem a desvantagem que você terá que escrever mais código produtivo de uma só vez, aumentando a dificuldade de encontrar todos os erros que foram introduzidos.
2. Testar após o fato.  Nesta abordagem você escreve um pouco de código produtivo e então escreve bastante teste para valida-lo. Esta abordagem tem a vantagem de que você pelo menos está validando o código mas tem a desvantagem de que você perde o benefício inerente do design de escrever o teste primeiramente.
3. Não testar tudo. Esta é realmente uma péssima idéia.

Coisas boas para saber

1. Uma regra assumida pelo TDD é que você tenha um framework de teste unitário disponível. Os desenvolvedores de software Ágeis usam com freqüência a família de ferramentas de código aberto xUnit, tais como JUnit ou VBUnit, embora as ferramentas comerciais também sejam opções viáveis.   

2. Design Orientado a Teste (TDD) = TFD + Refatoração

3. TFD/TDD é normalmente usado com código orientado a objeto de negócio, embora você também possa usar esta abordagem para código processual, código de interface de usuário e o código da sua base de dados se você quiser.

4. Uma discussão mais completa sobre TFD e TDD é apresentada em Introdução ao Desenvolvimento Orientado a Testes (TDD).