TDD - Caso de Sucesso

[Cassio Pinheiro Almeron]

Olá,

Gostaria de compartilhar com os senhores um caso de sucesso que tive com TDD.

Na empresa onde trabalho, mantenho um software que tem a responsabilidade de receber arquivos Xml de notas fiscais eletrônicas de fornecedores.
O processo crítico deste software é justamente o recebimento dos arquivos Xml através de leitura de caixa de e-mail.

Este software foi concebido a uns 2 anos, e fora desenvolvido com modelo anêmico, e as regras de negócio em classes de serviço.
Após dois anos, o fonte deste processo já estava meio bagunçado. e após ter estudado um pouco de DDD e já ter praticado TDD, resolvi reescrever este processo.

Então reescrevi com modelo rico, seguindo o princípio que uma classe deste modelo nunca deverá entrar em um estado inválido, e ao longo do desenvolvimento criando os testes para validar estes modelos.
Uma regra de negócio deste modelo é consultar no Sefaz (Web Service da Receita Federal) a situação da nota fiscal.
O Sefaz foi considerado Infra-Estrutura, por isso a lógica de comunicação foi isolada em uma outra camada, e a chamada para o mesmo sendo chamado através de interface (desacoplamento).
Para validar o Comportamento do modelo, (as respostas do web-service, falha de comunicação), nos testes o Sefaz é substituído por um Stub, onde nestes podemos simular diversas situações de respostas.

Também foram realizados testes sobre a classe que orquestra a leitura da caixa de e-mail, onde o componente de acesso a Pop/Imap também fora isolado e chamado por interface.

Após o fim deste trabalho, atualizei aos poucos todos os clientes.
E o resultado foi que a equipe do suporte, ou até mesmo clientes, nunca mais me relataram problemas na importação de notas.
Até chegou a acontecer uma pequena situação em produção, mas bastou apenas escrever o teste com as características do ocorrido, para pegar o bug, e resolver.

Com isso a conclusão que eu chego é que TDD realmente é produtivo e eficiente ao mesmo tempo.
No início parece que é mais demorado por implementar os testes além do código, mas na prática é que ganhamos tempo considerável ao validar os processos implementados.
TDD não é difícil, mas para aprender não é natural, é necessário uma grande quebra de paradigma.
Escrever os testes depois também é interessante, mas escrever antes é melhor porque a cada passo que implementamos do processo, escrevemos um teste para valida-lá, e assim surgem vários casos de testes, e consequentemente maior cobertura. O mesmo não acontece ao testar depois.