Todo teste unitário começa com o banco zerado
Todo. Todo zerado. Não faça um teste depender do sucesso ou fracasso de outro teste!
Testes que rodam sem limpeza do banco facilmente dão a sensação de que é okay rodar os testes num banco de desenvolvimento, e irão rodar já conspurcados pelos dados que habitam o banco.
Na verdade, testes unitários deixam de ser “unitários” se sua execução depender de fatores externos. Ou seja: eles não podem depender de
- Dados que já habitem o banco de dados;
- Arquivos de configuração do projeto;
- Variáveis de ambiente;
- Condições meteorológicas.
Isso porque o teste é criado com todas as condições já reguladas para que determinados comportamentos sejam realmente testados. Se acontece de que “os testes passam na minha máquina, mas não na sua”, você fez algo errado.
Existe um bom motivo para que os testes rodem sempre isolados: quando você descobrir um bug daqueles bem cabeludos, vai querer ter certeza de que ele reside realmente no código e não num problema relacionado à ordem com que os testes são executados, por exemplo.
Testes servem para capturar problemas, e quando problemas acontecem, dúvida, suspense e mistério são justamente mais problemas, não vantagens. O bug em si já é dúvida o bastante, então devemos tentar rodeá-lo do máximo de clareza que conseguirmos. Se seus testes são interdependentes, um bug que afetaria apenas um deles, levando-o a um processo de depuração muito mais focado, começará a afetar N outros, potencialmente gerando muita confusão.
Testes devem rodar do mesmo jeito, independente de ser a primeira ou a quinquagésima vez que rodam. Testes que “na segunda vez quebram” estão errados.
Lembra que falei sobre “condições meteorológicas”? Pois é. Seus testes unitários não devem depender de I/O fora do seu controle. Se seu código lê arquivos, estes devem constar como fixtures dos testes. Se consulta uma API externa, as respostas devem ser mockadas de alguma forma, seja com código seu, seja com “gravação” ao estilo vcrpy.
Testes devem ser escritos com código meio burrão, mesmo. Se você precisa testar várias variações de uma sequência de passos, você escreverá um teste para cada variação e repetirá bastante código entre cada teste. E é okay. Quando descobrir um problema, você saberá exatamente qual é a sequencia defeituosa e gastará seu tempo tentando entender o código, não o teste.
(É, esse artigo saiu meio como um conjuntão de ideias. Peço desculpas. Um dia escreverei algo mais “inspirado”.)
Curtiu? Então assine a minha newsletter e receba conteúdo interessante em pequenos drops direto na sua caixa de e-mails:
Sugestão de leitura: Team Topologies: Organizing Business and Technology Teams for Fast Flow
