Todo bom desenvolvedor sabe que testes automatizados são importantes. Ainda assim, boa parte dos desenvolvedores não entende o valor do TDD (Test Driven Development). Argumentam que o importante é testar, não importa quando. É um argumento pertinente, e eu mesmo sou culpado de tê-lo usado algumas vezes no passado. Mas será que está certo?

Analisando o argumento, notamos que quem o faz entende que testar é algo importante. Isso já é um grande passo. No Ágiles 2009 foi citado que apenas 2% dos desenvolvedores fazem testes, ou seja, se você faz testes você pode estar fazendo parte de uma minoria que sabe fazer software direito. Testes trazem grandes benefícios, garantem que o código da aplicação funciona hoje, e vai continuar funcionando no futuro. Testes feitos antes ou depois garantem isso da mesma forma. Diante disso, argumenta-se: porque testar antes?

Porque tal argumento é falho?

É falho porque entende TDD como uma abordagem de testes. TDD utiliza testes para dirigir o desenvolvimento da aplicação, mas o foco não são os testes, mas sim o design da aplicação. Testes escritos antes do código da aplicação, antes de serem testes, são especificações. Depois do primeiro verde do ciclo do TDD e antes da refatoração, as especificações podem ser chamadas de testes, mas até então elas não testavam nada, elas especificavam um comportamento que deveria existir, mas não existia ainda.

Há uma diferença muito grande entre testar antes e testar depois: quando você testa antes você está especificando, e depois a especificação vira um teste. Quando você testa depois você está garantindo que algum código que você escreveu funciona, você está somente testando, não especificando.

Testes feitos antes garantem que o código criado vai ser testável, e, provavelmente, vai ser mais desacoplado do que seria se os testes tivessem sido escritos depois. Especificações focam na maneira com que uma API vai ser usada, e por este motivo a API tende a ficar também mais simples de usar, já que o uso e os nomes das entidades (classes, métodos, eventos, etc) são todos definidos sob a perspectiva do usuário da API, e não do construtor dela. São definidos de fora, e não de dentro. Outro grande benefício é ter muito claro como se usa uma API: está com dúvida, olhe as especificações.

Quando você para para observar um desenvolvedor praticando TDD, você nota outra coisa interessante: ele raramente usa o depurador. Isso acontece porque praticamente não há necessidade de utilizá-lo, já que, se um teste falhou, só pode ter sido por causa do código que você escreveu nos últimos 5 minutos, já que antes os testes passavam. Rapidamente você encontra o problema. Quando você faz testes depois, frequentemente há a necessidade de usar o debugger.

Diante disso, volto ao título do Post: TDD não existe, porque não são testes que dirigem o desenvolvimento, mas sim especificações, e há uma grande diferença, porque nem sempre testes são especificações. Um nome mais adequado seria Specification Driven Development, ou Specification Driven Design (SDD).

Encerrando, é sempre bom dizer:

• Se você nunca praticou TDD e pratica testes, não conhece o benefício de uma API desenvolvida sob a perspectiva do usuário, e os benefícios que isso trás. Experimente.
• Se você não faz testes, você está com um problema gigantesco em mãos. Como diz o Uncle Bob, desenvolvedor que não testa é como cirurgião que não lava as mãos. Quando você não está testando você está deixando de realizar uma das práticas mais importantes da sua profissão, o que o coloca, efetivamente, na condição de amador. Que tipo de profissional você quer ser?

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.