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 de desenvolvedor. Você necessita de código fonte apenas para fazer o erro acontecer. Por exemplo, um novo método prestes a ser adicionado a uma classe poderá ser criado apenas para provocar uma exceção fatal.
2. Execute os seus testes. Você executará basicamente a suíte completa de teste, embora por causa da velocidade você possa decidir executar somente um subconjunto. O objetivo é assegurar que o novo teste falhe de fato.
3. Atualize o código produzido. O objetivo é adicionar apenas a funcionalidade necessária para que o código passe no teste.
4. Execute sua suíte de teste de novo. Se os testes falharem você terá que atualizar o código funcional e testá-lo de novo. Uma vez que os testes passem repita os passos.

Por Que TFD?

Uma vantagem significativa do TFD é que ele lhe 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ê tiver escrito apenas cinco linhas novas de código ao invés de cinqüenta. A implicação disto é que, o quão mais rápido forem seu compilador e sua suíte de teste de regressão, mais atrativo será continuar com passos cada vez menores.

Existem outras três estratégias comuns de teste (listadas aqui 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 a causa de erros novos.
2. Testar após o fato. Nesta abordagem você escreve um pouco de código produtivo e então escreve bastante teste para validá-lo. Esta abordagem tem a vantagem de que você, pelo menos, ainda está validando o código, mas tem a desvantagem de que você perde o benefício inerente do design de escrever o teste primeiramente.

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 comercial orientado a objeto, embora esta abordagem possa também ser usada para código processual, código de interface de usuário e código de base de dados.