Tecnologia / Artigos / O Guia Definitivo do Design de Software /
Todo teste unitário começa com o banco zerado

Cléber

![livrinho-aberto-em-branco-com-lapiseira.jpg](/files/154) *Photo by [Mike Tinnion](https://unsplash.com/@m15ky) on [Unsplash](https://unsplash.com/s/photos/blank)* --- 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 1. Dados que já habitem o banco de dados; 2. Arquivos de configuração do projeto; 3. Variáveis de ambiente; 4. 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`](https://vcrpy.readthedocs.io/en/latest/). 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".)

Curti

36 visitantes curtiram esse Item.

Anterior: Faça uma coisa por vez | Próximo: Teste tudo