O que são testes unitários integrados

Introdução

Venho tendo a oportunidade de trabalhar em um projeto no qual os desafios são bem interessantes e bem fora do comum principalmente quando se trabalha com desenvolvimento mobile. Estes desafios envolvem resolver algoritmos com entrada e saída muito bem definidos e para esses casos venho encontrando um padrão que tem dado muito certo para mim que é fazer testes integrados mas a nível unitário.

A primeira coisa que vem na mente quando falamos em testes integrados é rodar a aplicação inteira e testar todas as peças de forma integrada, mas isso é bem custoso independente do tipo da sua aplicação e não é esse tipo de teste que quero falar hoje.

O que é

Os testes unitários integrados é basicamente seguir uma abordagem de não usar mocks para fazer o testes. Parece estranho essa afirmação, né? Bom, mas é exatamente isso que venho fazendo para esses casos onde tenho algoritmos complexos ou classes que foram quebradas mas fazem parte de uma única solução.

Normalmente em um cenário usamos mock para todas interações externas e focamos somente na classe a ser testada, e na grande maioria das vezes isso faz total sentido. Mas nesse caso onde eu tive que quebrar meu algoritmo em mais classes pelo simples fato de não querer aumentar a complexidade de uma classe isolada, acaba que pra eu ter a total certeza que a entrada e saída estão corretas, tenho ido pra essa abordagem de não usar mocks. Isso tem aumentado e muito a minha confiança nos testes pois não preciso ficar mockando todas interações externas sendo que meu algoritmo depende delas e elas sozinhas não faz muito sentido.

Onde utilizar

Isso é o que tem dado certo para mim e é o que tem feito aumentar minha confiança ao gerar uma versão, pois sabendo que estou realmente testando o que o usuário vai usar e de certa maneira unitariamente, então não preciso me preocupar em atualizar algum mock quando uma lógica interna foi alterada ou até mesmo sair mudando verificações de mock porque tive que mudar a chamada de uma classe de lugar.

Esses cenários de não utilizar mock e fazer testes unitários integrados eu vejo que faz sentido quando algum código é grande o suficiente para ter que quebrar ele em mais classes e quando tem uma entrada e saída muito bem definida. Casos onde é uma simples chamada de serviço, ou uma regra de negócio que depende de um banco de dados por exemplo, para esse cenários mais comuns faz total sentido mockar as interações externas.

Conclusão

Nesses casos de algoritmos eu testo todas as classes abaixo dessa classe de entrada e todas elas sem utilizar mock, mesmo que essas classes acessem outras classes utilitárias. E isso tem aumentado e muito a confiabilidade nos testes e também tem me ajudado a achar mais bugs no meu código. Além disso eu reduzo meu trabalho quando preciso alterar o algoritmo e se ele quebrar é porque realmente fiz alguma cagada e não porque mudei uma chamada de lugar. No fim acabo focando mais em testes que realmente testam invés de simplesmente ter um coverage alto que não garante nada.

Me siga nas redes e fique por dentro de mais publicações:

Twitter: twitter.com/tuliohmagalhaes
Instagram: instagam.com/tuliohmagalhaes
Facebook: fb.com/tuliohmagalhaes
Linkedin: linkedin.com/in/tuliohmagalhaes
Telegram: t.me/tulio_magalhaes