Testes automatizados com Junit e Mockito: Por favor, pare de usar matchers de argumentos

No episódio discutimos sobre a importância de escrever testes automatizados que busquem se aproximar o máximo possível da execução real do código.

A ideia é que seus testes aumentem a confiabilidade da aplicação. Se você abusa de mocks e matchers de argumentos, os testes ficam mais distantes de alcançar o objetivo de aumento de confiabilidade.

Assista o episódio e tire suas próprias conclusões :).

# Sobre a Jornada Dev Eficiente

Temos um treinamento cujo objetivo é fazer com que você busque as melhores posições como Dev impulsionado pela sua profundidade técnica em Design e Arquitetura de Software.

Trabalhamos quatro grandes áreas:

1. Capacidade técnica em Design e Arquitetura de Software
2. Capacidade de aprendizagem cada vez mais eficaz
3. Capacidade de impactar o meio através do seu conhecimento
4. Grande poder de execução

# Saiba mais sobre Alberto, Aniche e Rafael

[SamylaDutra]

Muito boa essa reflexão! As vezes temos o ímpeto de escrever o teste muito genérico e aí ele deixa de ser assertivo.

[GuilhermeVianaFreire]

Excelente informação sobre mocks nos testes unitários. A não utilização de matchers não só aumenta a confiabilidade dos testes, como facilita o mock específico de multiplas chamadas do mesmo método mockado com valores de parâmetros diferentes.

[joaorodolphovitorcabral]

Fala meu bom, legal esse vídeo aí, sempre legal se aproximar da realidade da aplicação o máximo possível, me tira uma dúvida, vc sabe como se usa attachaprovider com o mockito?

[iagosaito]

Olá Alberto, boa noite!

Você acredita que o uso excessivo de Mocks acontece porque as pessoas têm na cabeça que testes unitários significam testar sempre a menor unidade possível (solitários), em vez de testar unidades sociáveis?

Na minha experiência, escrever testes um pouco mais sociáveis aumenta a confiabilidade do teste e diminuem o uso de mocks.

Confesso que eu utilizo Matchers em situações específicas: por exemplo, quando tenho uma classe que posta uma mensagem num tópico Kafka. Nesses casos de uso, eu acho que os Matchers especificos - sem nenhum tipo de Any(), cumprem bem a função.

O que acha?

Obrigado pelo vídeo.

[filipetortora]

Primeiramente excelente video, me fez pensar em todos os testes unitários que eu fiz utilizando any.

Faz sentido colocar um valor verdadeiro para um método que estou mockando o retorno?

Pelo que entendo da utilização de any no lugar de valores verdadeiros seria porque mesmo que eu coloque um valor verdadeiro, eu estou definindo qual será o retorno do método

A lógica de testar uma classe que utiliza um método de outra classe seria para testar todas as condições dentro da classe

Dessa forma, mesmo que eu utilize o any, eu posso definir o valor que eu quero retornar e testar todas as condições de acordo com o retorno do método que está fora da classe

Faria sentido eu colocar um valor especifico no lugar do any caso o retorno do método que eu estou mockando seja influenciado por esse valor

Isso ajudaria na legibilidade no teste unitário e facilitaria o programador que não fez o teste a entender o fluxo que está sendo testado.

Caso o valor que está sendo passado não influenciar no retorno do método que está sendo mockado, não vejo problema em passar um any