7 Benefícios que a Experiência com TDD me Trouxe
Se você acompanha nossa página, já deve ter notado que a equipe da Qualyteam preza muito por testes automatizados. Eles dão segurança e estabilidade necessárias para práticas como integração e entrega contínuas.
Em relação, principalmente a testes de unidade, TDD (test-driven-development) ainda é um tema que gera dúvida entre desenvolvedores. Minha experiência com TDD me fez melhorar muito como desenvolvedor. Acredito que compartilhar um pouco das minhas percepções pode ajudar vocês a darem uma chance para essa prática que envolve não só a preocupação com testes, mas também com o design do código.
Que tal analisarmos 7 benefícios percebidos na adoção do TDD?
1. Evitar passar horas apenas escrevendo testes
- “Acabei, só faltam os testes.”
Então não acabou. Lá se vão algumas horas apenas escrevendo testes, o que pode ser frustrante. Ao praticar TDD, teste e implementação acabam sendo escritos de forma rapidamente intercalada, tornando o processo muito mais dinâmico.
2. Realmente fazer os testes
Principalmente quando ainda está se criando uma cultura de testes, às vezes ao chegar no final da implementação, percebe-se que o esforço pra cobrir tudo que você fez com testes é maior do que a sua motivação para escrevê-los.
3. Melhorar a especificação da aplicação
Testes podem e devem servir de especificação. O primeiro passo do TDD é justamente anotar os testes que serão necessários. Essa etapa ajuda a compreender melhor o que deve ser feito e escrever melhores especificações.
4. Planejar melhor a implementação
Pensar é parte essencial do trabalho de todo desenvolvedor. Ao orientar o desenvolvimento aos testes, consequentemente acaba-se pensando e planejando melhor a implementação de acordo com as especificações.
5. Sentir que fazê-los agrega valor
Testes têm valor. A questão é que isso dificilmente é percebido pela equipe antes de uma refatoração. Usá-los para guiar o desenvolvimento é uma ótima forma de enxergar este valor desde o início do processo.
6. Escrever código mais testável
Ao escrever código que precisa atender a um teste, naturalmente esse código vai ser mais testável. Quando o teste fica para o final, há um risco do código ficar mais difícil de testar. Com o tempo e após algumas refatorações, o código tende a perder sua testabilidade.
7. Evitar adaptar o teste ao código
Em uma suíte de teste, não é incomum encontrar testes que estejam cobrindo uma parte do código que na verdade é bug. Ao usar TDD, a chance de isso acontecer é muito reduzida, já que será escrito código para atender ao teste e não teste para atender ao código.
Estas foram algumas melhorias perceptíveis que vieram da minha experiência com TDD. Hoje me considero um desenvolvedor melhor e tenho mais confiança no que produzo. Certamente nem todos compartilham das mesmas percepções e gostaria muito de saber sobre as suas.
Vocês já praticaram TDD? Comentem um pouco sobre suas experiências com testes (ou a falta deles).
