Quem tem utilizado desenvolvimento orientado por testes (TDD) sabe o quanto ele está diretamente ligado a design de código. Um design testável normalmente é um design desacoplado e reutilizável. TDD é muito mais sobre design do que sobre testes.

TDD é uma prática que envolve o desenvolvimento como um todo. Principalmente o design. Há quem diga que a sua última letra, a letra D, deveria significar design e não desenvolvimento. Ou seja, design orientado por testes.

Eu, particularmente, gosto muito dessa idéia. É como ter um design executável. TDD questiona o desenvolvedor freqüentemente sobre questões como princípio da responsabilidade única (SRP) e não se repita (DRY). Trata as violações das práticas de orientação a objetos. E ataca os pontos mais humanos, simplificando o projeto, onde se implementa somente o necessário (YAGNI).

Esses questionamentos são feitos a medida que sentimos a menor dificuldade em testar alguma coisa. Porque eu preciso depender de outro objeto pra testar apenas esse? Será que esse método deveria funcionar quando chamado por ele mesmo? Esse não era pra ser apenas um método de comando? Então porque alterou meu objeto?

TDD encoraja a testar e verificar cada componente do software independentemente. Isso faz o design emergir de forma extremamente simples e poderoso. Simples por tornar qualquer futura mudança ou manutenção fácil e rápida. Poderoso pela facilidade de extensão com um alto grau de segurança. Como estamos trabalhando com o teste executando a tarefa de um consumidor final e direto, conseguimos alcançar coesão e baixo acoplamento naturalmente. Passo a passo.

Sabemos que a qualidade do design de um software é também relacionada ao conhecimento da equipe de desenvolvimento em relação ao domínio em questão. E TDD também é extremamente influente nesse quesito. Tendo como testes executáveis o primeiro ciclo do desenvolvimento, é no mínimo necessário o desenvolvedor saber o que estará testando e onde ele quer chegar. É ele quem vai desenvolver os critérios de aceitação.

É impossível praticar TDD sem refatoração constante. E esse é o ponto-chave. Usufruindo dos ciclos de refatoração estamos a todo o momento focado no design. Coisa que não acontece em um fluxo tradicional de desenvolvimento.

Engana-se aquele que afirma que TDD não é produtivo. Muito pelo contrário. Por mais que em um primeiro momento o pareça improdutivo, definitivamente ele não é. No momento que focamos no design, e somente no que é essencial já estamos garantindo baixo desperdício. Sem contar que com todo o nosso código coberto por testes, evitamos aquelas longas sessões de depuração. E claro, sem falar no design. Legível, flexível, simples, eficiente, cuidadoso… De fácil manutenção. Quer algo mais produtivo? Sem contar que estamos movendo naturalmente para a idéia de zero defeito. E quanto mais defeitos mais retrabalho.

Uma ótima série de artigos escritos por Neal Ford, sobre arquitetura evolucionária e design emergente, mostra na prática o impacto que TDD causa no design de um software.

Aposte suas fichas no desenvolvimento guiado por testes e veja o design do seu código emergir com qualidade.

Versão em espanhol, por Diego Gomez: El impacto de TDD en tu diseño