Teste de Software: O que é TDD?

Cesar William Alvarenga

Jun 16, 2020·4 min read

O Test Driven Development (TDD) é um processo de desenvolvimento de software que segue os seguintes passos:

1. Escreva um teste para uma função (este teste irá falhar).
2. Implemente código suficiente para fazer o teste passar.
3. Refatore o código com confiança (se necessário).

TDD e o método científico

TDD é como o método científico, mas para software. O método científico é como aprendemos coisas sobre o mundo. Funciona assim:

1. Faça uma observação.
2. Faça uma pergunta sobre a observação.
3. Forme uma hipótese ou explicação testável da observação.
4. Faça uma previsão com base na hipótese.
5. Teste a previsão.
6. Itere: use os resultados para fazer novas hipóteses ou previsões.

Vamos dividir isso em elementos mais simples:

1. Pergunta
2. Fazer uma predição
3. Experimentar
4. Resultado

Com o TDD, em vez de aprender coisas sobre o mundo, estamos criando um novo mundo que deve estar em conformidade com nossas especificações. Em vez de começar com uma observação sobre o mundo real, começamos com um requisito. TDD vira o processo de cabeça para baixo. Em vez de aprender sobre o mundo real, estamos ajustando o método científico para criar um novo método.

Relação do TDD com o Método Científico

Pergunta: Requerimento
Fazer uma predição: Esperar um retorno específico
Experimentar: Implementar o teste para a predição
Resultado: Implementação do código

O fator chave no método científico e no TDD é a previsão. Depois que o resultado já é conhecido, as pessoas geralmente acreditam que poderiam ter previsto o resultado: que sabiam disso o tempo todo. No código, isto pode ter um efeito mais perigoso: seu código pode produzir um resultado errado, mas você pode acreditar que é um resultado correto.

Isto é muito comum nos testes com snapshots, uma forma de testes que alertam quando algo muda, e não quando algo está errado. Se você acabou de fazer uma alteração no código, e um teste com snapshots o alerta de que houve uma alteração, você já está esperando o alerta e é convencido a acreditar que o resultado está correto, o que o torna vulnerável a aceitar resultados incorretos.

Mas este efeito não se limita aos testes com snapshots. Freqüentemente, ao adicionar testes após a a implementação, os desenvolvedores tendem a aceitar o retorno que a função gera sem verificar cuidadosamente os resultados com testes manuais.

O TDD nos obriga a fazer um teste preditivo de um retorno esperado, porque o código que produzirá retorno real ainda não existe.

Com isso em mente, podemos aprimorar nosso processo TDD:

1. Traduzir um requisito em um teste que não irá passar.
2. Preveja o retorno esperado com base no requisito.
3. Execute o teste para obter a saída real. Deve falhar na primeira vez. Se passar, vá para o passo 1.
4. Escreva a implementação. O teste deve passar neste momento. Se falhar, repita esse passo.
5. Passe para o próximo requisito e repita o passo 1.

Os benefícios do TDD

• Elimina o medo da mudança. Se uma alteração de código introduzir um bug, os desenvolvedores serão alertados rapidamente, e o loop de feedback do TDD os notificará rapidamente quando for corrigido.
• Uma rede de segurança que torna a implantação contínua mais segura. As falhas de teste interrompem o processo de implantação, permitindo que você corrija os erros antes que os clientes tenham a chance de vê-los.
• 40% — 80% menos erros.
• Melhor cobertura de código do que escrever testes após a implementação. Como criamos código para fazer um teste específico passar, a cobertura do código será próxima de 100%.
• Loop com o feedback para o desenvolvedor será mais rápido. Sem o TDD, os desenvolvedores devem testar manualmente cada alteração para garantir que ela está funcionando. Com o TDD, os testes unitários podem ser executados a cada alteração automaticamente, fornecendo um feedback mais rápido durante o momento de desenvolvimento e debug.
• Ajuda no design de interface: os desenvolvedores costumam pensar na implementação do software antes de pensar na experiência do desenvolvedor que vai utilizar aquele componente de software. O TDD inverte isso, forçando os desenvolvedores a projetar a API antes de trabalhar na implementação.
• Keep it Simple, Stupid (KISS) e You Ain’t Gonna Need It (YAGNI) — “Mantenha as coisas simples, estúpidas” e “Você não vai precisar disso” são dois princípios de design de software que se sobrepõem. KISS significa exatamente o que parece. Mantenha as coisas simples. YAGNI significa não criar recursos e abstrações, a menos que esses recursos atendam a um requisito existente (não um requisito futuro). O TDD ajuda nesse processo, forçando você a trabalhar em pequenas iterações, atendendo a um requisito de cada vez, conforme a necessidade.

Custos TDD

Usuários sem experiência em TDD podem achar que vão desenvolver 15% a 30% mais devagar, mas com 1 a 2 anos de prática, o processo de feedback em tempo real do TDD pode aumentar a produtividade.

Dicas

• A previsão vem antes da implementação. (Testes com snapshots e teste após o desenvolvimento não se qualificam como TDD).
• Use pequenas iterações. Teste e codifique um requisito de cada vez.
• Refatore com confiança, mas somente quando for necessário.
• Aprender TDD é o mesmo processo de aprender a arquitetura de aplicações modulares. Geralmente, são necessários 1 a 2 anos de prática para que você fique bom nisso. Seja paciente. O TDD me ensinou muito do que sei sobre arquitetura de aplicações modulares.

Créditos

• Testing Software: What is TDD?, escrito originalmente por Eric Elliott