Desenvolvimento Guiado por Testes (Test Driven Development), ou simplesmente TDD, consiste numa técnica de desenvolvimento de software onde primeiro são criados os testes abrangendo a melhoria desejada e/ou novas funcionalidades e somente depois é implementado o código necessário para passar por eles. A disponibilidade de testes antes do código propriamente dito garante um desenvolvimento rápido e um feedback sobre qualquer mudança. Não somente maximiza a qualidade do seu código, como também simplifica o processo de desenvolvimento além do aumento da produtividade.
O TDD é uma das práticas do XP (Extreme Programming), e foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências. O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa criar sistemas de melhor qualidade e produzidos em menos tempo. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento de software e manter um processo contínuo de desenvolvimento em um ciclo curto, ou seja, desenvolver entregáveis em períodos curtos (iterações) que forneçam um feedback constante do estado do software.  (Nos próximos post’s pretendo abordar a filosofia e algumas práticas do XP).

Vejamos como é o ciclo do TDD:

1. Crie um teste: cada nova funcionalidade deve começar com um teste escrito. Este teste deve falhar antes mesmo da funcionalidade ser implementada. Por isso é importante conhecer claramente os requisitos e especificações da nova funcionalidade. (Isso também vale para correção de bug’s onde se deve sempre escrever os testes primeiro, para só então alterar o código propriamente dito).
2. Execute todos os testes: você saberá que a rotina de testes está funcionando corretamente e que o novo teste não passou sem que o teste da funcionalidade tenha sido implementada.
3. Escreva o código: escreva o código que irá passar naquele teste que você criou na etapa anterior. Não se preocupe muito com o “design” do código neste momento, é muito importante que este código implementado reflita somente o teste escrito.
4. Execute novamente todos os testes: se todos os testes passarem, você terá certeza que o código atende todos os requisitos testados e que esta nova funcionalidade não afetou outras partes do sistema.
5. Refatore o código: vá ajustando/otimizando o código se for necessário. Lembre-se de executar os testes constantemente durante esta etapa, pois só assim saberá se o sistema não foi modificado da maneira incorreta. Mantenha o hábito da refatoração constante em seus códigos e não tenha medo das mudanças, afinal os testes existem para isso.

TDD é um processo iterativo e você repete estes passos inúmeras vezes até que fique satisfeito com o novo código.

A maneira que o TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito. Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro, portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos benefícios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.

Quando se implementa testes unitários depois do código estar pronto, você tende a implementar testes de baixa qualidade, pois você inconscientemente escreve um teste para rodar no código produzido, e o correto seria o contrário, seu código é que deveria passar no teste previamente implementado.

Os testes, quando devidamente escritos, oferecem uma certa “garantia” de que a aplicação está funcionando da maneira como deveria.

E não esqueça: “Se testar é bom, vamos testar toda hora!”.

por Anderson Straube

Post original