Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas.

Este tipo de abordagem implica em alguns problemas, entre eles:

• o programador não tem segurança em saber quando uma implementação acabou;
• o programador não precisa implementar a classe de forma que ela fique desacoplada das demais;
• o programador tende a não desenvolver para a interface e sim para a implementação;
• métodos não coesos (fazem mais ou menos do que deveriam fazer);
• nomes de atributos e operações não representam adequadamente a funcionalidade.

O TDD pretende resolver todas as deficiências citadas acima e várias outras. Mas, o que é o TDD? TDD ou Test Driven Development pode ser considerada uma metodologia de design de software, onde escrevemos primeiro um teste e depois o código necessário para o teste passar. A idéia é que o desenho das classes seja guiado pelos testes. O TDD força o desenvolvedor a pensar primeiro em o que ele precisa, e em como fazer, via teste unitário, para testar se a implementação a ser feita fará o que deve, nada mais e nada menos. Com isso, se ganha em vários aspectos:

• as classes devem ser desacopladas, senão o teste não pode ser executado;
• os métodos são bem coesos, ou seja, fazem somente o necessário para o teste passar;
• o programador sabe exatamente quando concluiu uma implementação, pois o teste passou;
• o programador consegue validar rapidamente uma alteração que pode ter causado um impacto em outras unidades, apenas rodando um conjunto de testes;
• operações e atributos possuem nomes claros e representam exatamente o que fazem.

O workflow do TDD pode ser descrito basicamente em cinco passos básicos:

1. Crie a classe de teste e o primeiro teste
   1. Nesse ponto o programador deve pensar em como será a assinatura do método testado. O fato de ter que escrever um teste para o método, faz com que, tanto o nome quanto os parâmetros de entrada e saída sejam bem claros e coesos.
2. Compile o teste
   1. O teste não vai compilar. Neste momento, crie a classe e a declaração do método. Recompile e rode o teste. O teste deve falhar, pois o método testado ainda não está implementado.
3. Implemente o código testado de modo que o teste falhe
   1. O objetivo do teste é detectar defeitos, e essa fase é importante para averiguar se o teste está cumprindo seu papel. Geralmente codificar para que o método testado retorne um valor errado é o suficiente. Rode o teste e veja o teste falhar.
4. Agora corrija o código, de forma que o teste passe
   1. Implemente o suficiente para o teste passar. Você deve garantir que o teste exija o suficiente. Se precisar implementar mais do que o necessário para o teste passar, provavelmente seu teste não está bom o suficiente, ou seu método não está coeso. Neste caso, refaça o teste ou corrija a implementação do código testado.
5. Faça alguma refatoração necessária e reexecute os testes
   1. Na fase anterior nos preocupamos apenas em fazer o teste passar. Nessa etapa, faça uma revisão no código e veja se precisa de alguma refatoração. Em seguida rode todos os testes construídos até agora para certificar-se de que a refatoração não quebrou algum outro código.

Antes que me perguntem: TDD não é burocrático e demorado?.  Não. Usar TDD não implica em aumentar o tempo de desenvolvimento. Desconsiderando o tempo de adaptação de sua equipe, a tendência é que o desenvolvimento com TDD aumente consideravelmente a produtividade, e, consequentemente, a segurança e qualidade dos produtos desenvolvidos. Essa é a experiência de quase toda equipe de aderiu ao TDD, e provavelmente sua equipe só vai se sentir confortável com a idéia quando efetivamente aplicar os conceitos da metodologia.

Neste artigo não abordei as ferramentas de teste unitário, pois não é o foco do TDD, porém praticamente todos os ambientes de desenvolvimento moderno possuem algum framework de testes unitários. Posso citar alguns: NUnit (C#), DUnit (Delphi) e JUnit (Java). Escolha o que melhor se adequar a sua realidade.