Já defendi aqui nos posts o Test-First inúmeras vezes. Hoje, vou na linha oposta: quando o teste torna-se totalmente dispensável.

Imagine você entrando numa equipe para auxiliar a resolver uma lista de bugs existentes. Você faz algumas perguntas e obtém como respostas:

1. Os bugs em questão existem há tempos. Foram "consertados", porém "reapareceram";
2. O projeto tem seus 145 testes que rodam em 3 minutos;
3. Nenhum teste falha.

Primeira ação sua é obviamente dar uma olhada no /specs do projeto, pois as condições que ocasionam os bugs podem não estarem cobertas nos testes. Simples, você pensa. Só criar teste cases e pronto.

Criando o caso de falha

Seguindo o princípio da engenharia reversa, você deveria criar o teste que simula o bug. Ao abrir o código de teste, porém, você encontra um setup de 25 linhas, criando o chamado Persistent Fixtures do xUnit Patterns.

Todos os testes são de integração. Pelo menos, como diz o DHH, o teste de integração garante que seu código funciona.

Será ?

Você segue adiante. Vê duplicação de código de teste. Mas isso obviamente não importa, pois ele precisa apenas verificar que o código funciona. Você olha pelo código, procurando o melhor "lugar" para encaixar teus novos casos de teste até que se depara com nada menos do que o teste que está verificando aquela funcionabilidade esperada. E ele é Green.

O teste mudo

Ele não diz nada. Ele testa uma action da Controller e de brinde, passa pela funcionabilidade quebrada. Por ser um integration-all-in-one-full-stack teste, você não tem muito o que mudar, pois é basicamente um Input numa URL e a análise de um retorno. Neste cenário, você não tem o que mudar, pois o código de integração não garante que aquele bug apareça e seu teste finalmente falhe. Sua opção é tentar criar um Teste de Unidade.

One size fits all

Você percebe que o código de domínio totalmente ligado ao framework que você utiliza. Percebe que não poderá fazer um teste de unidade sem carregar junto nada menos do que 8 dependências. Mockar 8 coisas ? This is madness!

Como o framework é arquitetural, você está refém das convenções fornecidas por ele. Neste caso, você não tem muito o que fazer a não ser lamentar.

Fallback em debugging

Você desiste dos testes e decide que precisa resolver. Solução ? Partir para ferramentas de debugging. Com debug, você precisa entender variáveis e intra-código totalmente desnecessário para aquela tarefa porém, obrigatória no debugging uma vez que você precisa entender o fluxo (stack) da aplicação.

Depois de algumas boas horas, você percebe que o bug era na verdade uma infestação, pois havia mais de um lugar totalmente diferente que exercitava o código e criava o bug. Em miúdos: três telas utilizando duas regras totalmente diferentes para chegar a mesma solução. Lembre-se: Test-Driven development é desnecessário.

Concluindo

Você resolve o bug após várias horas. Faz teste manual e verifica que tudo está perfeito, inclusive seus testes continuam green, mostrando que aquela suite é totalmente dispensável e que teste sem propósito deveriar estar morto.

Essa pode ser uma história totalmente folclórica ou não.