Introdução ao Desenvolvimento Orientado a Testes

Test-Driven Development (TDD) ou Desenvolvimento Orientado a Testes é uma maneira diferente de escrever software. A diferença entre esta abordagem e a que você provavelmente está acostumado é que com TDD você vai evoluindo seu código aos poucos, conforme vai explorando o problema com o uso de testes automatizados escritos antes da solução sequer existir.

Em TDD, um teste é um pedaço de software. A diferença entre teste e o código que está sendo produzido é que os testes têm 2 funções principais:

• De especificação, ou seja, definir uma regra que seu software deve obedecer
• De validação, ou seja, verificar que a regra é obedecida pelo software

Geralmente os testes são criados com algum framework do tipo xUnit (jUnit, nUnit Test::Unit etc) , mas também podem ser feitos num nível de funcionalidades (através de softwares como o FitNesse e Selenium) . Estas ferramentas servem basicamente para organizar os testes e facilitar na criação das verificações.

O processo de criação de programação orientado a testes é simples:

1. Escreva um teste que falhe. Pense no que o código deve fazer, descreva o contexto e defina quais são as verificações que precisam ser feitas. Não há um limite no número de testes, então quanto menos coisa cada teste descrever/verificar, melhor. No início também não é preciso se preocupar se a classe/método ainda não existe. Pense primeiro no teste e só depois que este estiver pronto crie o esqueleto de código necessário para que ele compile e falhe ao rodar.
2. Faça o teste passar. Agora chegou o ponto crucial: escreva o mínimo de código para que o teste passe. Controle o instinto natural do programador de tentar prever tudo que o código vai fazer e apenas faça o teste passar. Mesmo que tenha certeza que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação agora.
3. Refatore. Uma vez que o teste passou, verifique o que no código pode ser melhorado. Geralmente para um teste passar é preciso inserir duplicação através de constantes (técnica conhecida como Fake It). Agora é a hora de melhorar o código e remover as duplicações, lembrando que os testes devem continuar passando.

Estes 3 passos são repetidos até que não se consiga pensar em novos testes, o que indica que a funcionalidade está pronta.

Algumas vantagens desta abordagem são:

• Incentiva a simplicidade: como a solução vai surgindo pouco a pouco, a tendência é que não se perca tempo com aquilo que não tem certeza que será usado em seguida. Expressões como “You Ain’t Gonna Need It (YAGNI)” e “Keep It Simple, Stupid (KISS)” são recorrentes quando se está programando orientado a testes.
  
• Aumenta a confiança no código: o sistema funciona de uma determinada maneira porque existem testes que foram utilizados durante sua criação e validam o que foi criado. E se ainda assim algum erro surgir, um novo teste é criado para reproduzí-lo e garantir que depois de solucionado ele não irá se repetir.
• Ajuda como documentação: os testes quando bem definidos são mais simples de ler que o código e, embora nem sempre sirvam como uma especificação para o usuário final, eles são uma fonte eficiente para entender o que o software faz. Além disso, esta documentação sempre estará atualizada com a aplicação.
• Facilita refactorings: quanto mais testes existem no sistema, maior é a segurança para fazer refactorings. Um erro causado por algum refactoring dificilmente vai passar desapercebido quando um ou mais testes falharem após a mudança.

Bibliografia:

SAMCHEZ, Ivan. Introdução ao Desenvolvimento Orientado a Testes, Coding Dojo Floripa. 07/11/06. Disponível em: http://dojofloripa.wordpress.com/2006/11/07/introducao-ao-desenvolvimento-orientado-a-testes/