As Três Leis do TDD

O que é o Desenvolvimento Baseado em Testes ou TDD?

Quais são as Três Leis do TDD?

É isso o que veremos neste post. Veja nesta página os posts da série sobre TDD.

O que é TDD

Desenvolvimento Baseado em Testes, o qual nos referimos pela sigla TDD (do inglês Test-Driven Development), é uma técnica de desenvolvimento de código que foca em criar os testes de unidade em simultaneamente ao código de produção.

No TDD primeiro é criado o teste e, só depois disto, é criado o código de produção. O código de produção é desenvolvido baseado nos testes. Por isso a técnica TDD tem esse nome.

As Três Leis do TDD

O TDD pede que primeiro criemos um teste que falhe para então escrevermos apenas o código de produção que faça o teste passar. Isso é exemplificado pelas Três Leis do TDD, mostradas a seguir, adaptadas do livro Código Limpo, por Robert C. Martin:

Primeira Lei: Escreva código de produção apenas quando exigido por um teste de unidade que falha.

Segunda Lei: Pare de escrever o teste assim que ele falhar. Não compilar é falhar.

Terceira Lei: Escreva o mínimo de código de produção, apenas o necessário para fazer o teste passar.

Abaixo vemos as explicações das leis e elas sendo utilizadas para o desenvolvimento de uma função que retorna o quadrado de um número.

A Primeira Lei

Primeira Lei: Escreva código de produção apenas quando exigido por um teste de unidade que falha.

A primeira lei evita que código de produção seja escrito sem motivo. No TDD, o único motivo para o código existir é para fazer um teste passar.

Dessa forma, é preciso ser capaz de escrever um teste que demonstra como o código de produção vai ser usado e como ele deve se comportar.

• Como o código vai ser usado: nome da função, quantos parâmetros e tipos dos parâmetros e do retorno
• Como o código vai se comportar: o que retornar com certos valores nos parâmetros.

TESTE(Quadrado_Parametro2_Retonrna4)
{
    TESTE_IGUAL(4, Quadrado(2));
}

A Segunda Lei

Segunda Lei: Pare de escrever o teste assim que ele falhar. Não compilar é falhar.

A segunda lei evita que vários testes sejam criados sem o desenvolvimento do código de produção correspondente.

Dessa forma temos um ciclo rápido de escrita de teste e escrita de código de produção. Esse ciclo é chamado de Red-Green (Vermelho-Verde), onde o vermelho identifica algum teste falhando e o verde identifica todos os testes passando.

int32_t Quadrado(int32_t valor)
{
    return 4;
}

Como assim, retornar quatro?! É aqui que entra a terceira lei:

A Terceira Lei

Terceira Lei: Escreva o mínimo de código de produção, apenas o necessário para fazer o teste passar.

A terceira lei evita que o código de produção se torne complexo sem motivo. Faça o mínimo necessário para fazer o teste passar. Faça todas as suposições possíveis.

No exemplo acima, eu assumi (supus) que a função Quadrado() só iria ser chamada com o parâmetro igual a 2. Então retornar 4 está ótimo.

Esta lei é contraintuitiva, porém ela mostra como apenas um teste não é suficiente.

Então, com o primeiro teste passando, escreva um teste adicional que faça essa suposição falhar. O novo teste vai fornecer uma perspectiva a mais e, consequentemente, vi dar mais segurança sobre a funcionalidade.

TESTE(Quadrado_Parametro3_Retonrna9)
{
    TESTE_IGUAL(9, Quadrado(3));
}

int32_t Quadrado(int32_t valor)
{
    return valor * valor;
}

Suposições: Quando Parar

Quando é a hora de parar as suposições? Quando elas começarem a dar mais trabalho do que a solução final. No caso anterior, eu poderia criar uma equação de reta que passa pelos pontos (2,4) e (3,9). Faria o teste passar e exigiria um novo teste. Porém parece ser muito trabalho.

O desenvolver das suposições pode depender dos testes. Por exemplo, se os testes fossem:

TESTE_IGUAL(0, Quadrado(0));
TESTE_IGUAL(1, Quadrado(1));
TESTE_IGUAL(4, Quadrado(2));

Talvez as suposições teriam sido:

return 0;             // Só chamado com 0.
return valor;         // Só chamado com 0 ou 1.
return valor * valor; // Final.

Considerações Finais

O TDD, ou Desenvolvimento Baseado em Testes, é uma técnica de desenvolvimento de software que preza por criar testes de unidade ao mesmo tempo em que o código de produção é desenvolvido.

Existem três leis que explicam a técnica e é importante segui-las para aprender o processo. Com a experiência é possível flexibilizar-se um pouco.

Geralmente, apenas um teste é pouco. É importante que haja o número adequado de perspectivas.