10 Dicas para escrever bons testes de unidade
Como estabelecer algumas regras para escrever testes de unidade realmente bons e sustentáveis? Eis algumas dicas que podem ser úteis:
#1. Que sejam curtos
Uma vez que estamos testando um pequeno recurso, fornecido por uma única unidade de código, faz sentido que um teste seja razoavelmente curto. Mas, quão curto? Bem, isso depende de vários fatores, mas geralmente não mais do que algumas linhas de código.
#2. Não se repitam
Boas práticas de codificação aplicam-se ao código de teste da mesma forma que se aplicam ao código em produção. Uma das regras mais comumente violadas em testes unitários é DRY. Algumas pessoas afirmam que os testes unitários não devem compartilhar nenhum código. Claro, você quer manter seus testes tão legíveis quanto possível, mas copiar e colar as coisas ao redor não é a solução.
#3. Prefira a composição [composition] sobre a herança [inheritance]
Uma vez que você reconheceu os dois pontos anteriores, pode se sentir tentado a criar algum tipo de classe-base para o seu teste que conterá código comum. Se você fizer isso, pare aqui mesmo! Essa classe-base funciona como um ímã para todos os tipos de código compartilhados não relacionados e cresce muito rapidamente até assumir seu projeto, sua empresa e até mesmo seu cão. Proteja seu cão, use a composição!
#4. Faça com que sejam rápidos
Os testes unitários são algo que você deve executar quase todo o tempo. Por esse motivo, certifique-se de abolir dependências externas e outras coisas que possam atrasar seus testes. Isso geralmente será bancos de dados, sistemas externos ou operações de arquivos. Ao mesmo tempo, não exagere nisso – o isolamento completo da unidade sob teste também não é uma boa solução.
#5. Torne-os deterministas
Testes unitários devem estar funcionando 100% do tempo: 100% de testes significa que tudo está bem (com as unidades, você também precisa de outros tipos de testes). Se os testes da sua unidade parecem falhar, certifique-se de encontrar a causa raiz e a corrija o mais rápido possível.
#6. Não ignore os testes
Dado os pontos 4 e 5, é particularmente importante mencionar que adicionar a anotação @Ignore ao seu teste não é uma maneira de consertar a suite de testes. Mas é uma maneira de tornar a suite de testes ainda menos confiável porque agora não está protegendo de bugs de regressão e que tais.
#7. Teste seus testes
Sim, você leu direito. Não se trata de escrever testes de seus testes, mas práticas como testes de mutação, desenvolvimento orientado por teste ou frequentes “changing random stuff” na base de código para ver se algum teste falha. Também pode ajudar fazer o exercício mental de tentar chegar a mudanças possíveis no código que os testes não cobririam.
#8. Saiba nomear bem seus testes
Não, shouldThrowException não é um bom nome para o teste. Embora não haja a necessidade de cada projeto levar convenções de nomeação extravagantes para os testes, é fundamental saber qual parte do código está quebrado apenas lendo os nomes dos casos de teste que falharam.
#9. Uma asserção lógica por teste
Para alcançar o objetivo de poder dizer o que há de errado apenas lendo os nomes dos testes que falharam, é preciso algo mais do que apenas bons nomes. Uma série de coisas verificadas pelo teste unitário deve ser limitadas também. Portanto, um bom teste de unidade deve conter apenas uma afirmação lógica, ou seja, verifique apenas um efeito de output/side do método testado.
#10. Desenhe seus testes
Esta é uma meta-dica, que abrange todas as outras dicas neste artigo e todos aqueles que não foram mencionados aqui. Trate seus testes com o mesmo rigor com o qual você trata seu código de produção. Considere os bons princípios e indicadores de design, como o baixo acoplamento entre o código de teste e o código de produção, e também duplicação, dead code e outros. Lembre-se de que uma boa suite de teste pode tornar sua vida muito mais fácil, fazendo com que você se sinta seguro ao mudar e refatorar seu código, enquanto uma suite de teste ruim pode desperdiçar muito tempo e tornar o código quase impossível de alterar depois.
Fonte: DZone.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.