Teste de Software: O que é TDD?
O Test Driven Development (TDD) é um processo de desenvolvimento de software que segue os seguintes passos:
- Escreva um teste para uma função (este teste irá falhar).
- Implemente código suficiente para fazer o teste passar.
- 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:
- Faça uma observação.
- Faça uma pergunta sobre a observação.
- Forme uma hipótese ou explicação testável da observação.
- Faça uma previsão com base na hipótese.
- Teste a previsão.
- Itere: use os resultados para fazer novas hipóteses ou previsões.
Vamos dividir isso em elementos mais simples:
- Pergunta
- Fazer uma predição
- Experimentar
- 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:
- Traduzir um requisito em um teste que não irá passar.
- Preveja o retorno esperado com base no requisito.
- Execute o teste para obter a saída real. Deve falhar na primeira vez. Se passar, vá para o passo 1.
- Escreva a implementação. O teste deve passar neste momento. Se falhar, repita esse passo.
- 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
