O TDD é uma sigla da palavra em inglês Test Driven Development, que traduzido para o bom português tupiniquim é Desenvolvimento Orientado por Testes. O TDD é uma das práticas de desenvolvimento de software sugeridas por diversas metodologias ágeis, como a XP. A ideia é que o desenvolvedor escreva testes automatizados constantemente durante todo o desenvolvimento, mesmo antes da implantação.
O código limpo que funciona é o objetivo do desenvolvimento orientado para testes (TDD).
O código limpo que funciona é um objetivo valioso por muitas razões. Ele é uma maneira previsível de se desenvolver. Você sabe quando termina sem ter que se preocupar com uma longa trilha de erros. Dá a oportunidade de aprender todas as lições que o código tem para ensinar. Se você só fizer a primeira coisa que você pensa, então você nunca terá tempo para pensar em uma segunda coisa melhor.
As duas regras do TDD
Desenvolvimento Orientado por Testes
No TDD temos duas regras: Só escrevemos um novo código se um teste automatizado falhar e temos de eliminar a duplicação
São duas regras simples, mas geram comportamentos individuais e de grupo complexos com implicações técnicas como:
- Devemos projetar organicamente com código, executando e fornecendo feedback entre as decisões.
- Temos que escrever nossos próprios testes, pois não podemos esperar 20 vezes por dia para outra pessoa escrever um teste.
- Nosso ambiente de desenvolvimento deve fornecer uma resposta rápida a pequenas mudanças.
- Nosso design deve consistir em muitos componentes altamente coesos e mal acoplado para testes fáceis.
Ambas as regras implicam uma ordem para tarefas de programação.
- Vermelho: Escreva um pequeno teste que não funcione e não possa sequer ser compilado inicialmente.
- Verde: Faça o teste funcionar rapidamente, mesmo se você cometer quaisquer pecados necessários no processo.
- Refatoração: Remova todas as duplicatas criadas apenas para fazer o teste funcionar.
O TDD pode reduzir a densidade de defeitos de código e tornar o assunto do trabalho muito claro para todos os envolvidos. Assim, escrever apenas o código exigido pela falha nos testes também tem implicações sociais.
- Se a densidade de defeitos pode ser reduzida, então o controle de qualidade (QA) pode passar do trabalho reativo para o trabalho proativo.
- Se o número de surpresas desagradáveis pode ser reduzido o suficiente, os gerentes de projeto podem estimar com precisão o suficiente para envolver clientes reais no desenvolvimento diário.
- Se as conversas técnicas se tornarem claras o suficiente, os engenheiros de software podem trabalhar em uma colaboração que acontece minuto a minuto, em vez de diária ou semanal.
- Se a densidade de defeitos pode ser reduzida o suficiente, então podemos ter software pronto com novos recursos todos os dias, o que gerará novos relacionamentos comerciais com os clientes.
Vantagens do TDD
Desenvolvimento Orientado por Testes
Concentre-se em testes, não em implantação.
O programador só pode pensar sobre o que a classe deve fazer e esquece a implementação por um momento. Isso ajuda você a pensar em melhores cenários de teste para a classe em desenvolvimento.
O código nasce testado
Todo o código de produção escrito tem pelo menos um teste de unidade verificando se ele funciona.
Simplicidade
Tornar o código mais simples, você acaba fugindo de soluções complexas, comuns em todos os sistemas. O praticante do TDD escreve código que só resolve os problemas que são representados por um teste de unidade.
Melhor reflexão sobre o design da classe
No cenário tradicional, a falta de coesão ou excesso de acoplamento é muitas vezes causada pelo desenvolvedor apenas pensando na implementação e acaba esquecendo como a classe vai funcionar contra o todo.
Ao começar com o teste, o desenvolvedor pensa em como sua classe deve se comportar em relação às outras classes do sistema.
O teste funciona como o primeiro cliente da classe a ser escrito. Nele, o desenvolvedor toma decisões como o nome da classe, seus métodos, parâmetros, tipos de retorno, etc.
No final, todas essas são decisões de design, e quando o desenvolvedor pode olhar atentamente para o código de teste, a qualidade do design em sua classe pode aumentar consideravelmente.
Muitos de nós gostam de complexidade
“ser simples” não é fácil. Afinal, TDD é uma tarefa técnica e que demanda esforço, porém os seus resultados valem cada minuto de esforço.
Newsletter HNZ
Você gostou do conteúdo? Siga nossa newsletter e receba semanalmente artigos e vídeos da HNZ! Clique aqui!
