🎭 3.3 Mocks Estritos e o Perigo do Acoplamento

O uso de Mocks introduz um acoplamento sutil entre o teste e a implementação interna da classe. Enquanto um teste de unidade tradicional foca no resultado (State-based testing), o teste com Mocks foca na interação (Interaction-based testing).

🏗️ O Equilíbrio da Verificação

Ao usar Mocks, seu teste “conhece” as dependências da classe. Se você trocar o nome de um método na interface LeilaoDao, todos os seus mocks falharão.

📄 Verificação explícita com verify()

O verify() garante que um efeito colateral necessário ocorreu (ex: o objeto foi atualizado no banco).

// Garantindo que o método atualiza foi chamado exatamente uma vez para o leilao1 verify(daoMock, times(1)).atualiza(leilao1);

---
 
## 📊 Comparativo: Estado vs Interação
 
| Critério | Teste de Estado (State) | Teste de Interação (Mock) |
| :--- | :--- | :--- |

| Foco | O valor retornado pelo método. | Se a dependência foi chamada corretamente. | | Ferramenta | assertThat(resultado)... | verify(mock).metodo(...) | | Risco | Pode ignorar efeitos colaterais. | Acoplamento forte com a implementação. |


🛡️ Boas Práticas de Mocking

  1. Não Mocke Tudo: Classes de domínio simples (Lance, Leilao) devem ser usadas reais. Mocke apenas infraestrutura (DB, API, Email).
  2. Prefira Stubs a Mocks: Use when(...).thenReturn() para prover dados. Use verify() apenas quando a chamada for uma regra de negócio essencial (ex: “tem que enviar o email”).
  3. Mocks Estritos: O Mockito 5, por padrão, é flexível. No entanto, você pode configurar mocks estritos para garantir que nenhuma chamada inesperada ocorra, embora isso possa tornar os testes mais frágeis.

O Segredo da Refatoração ⚡

Se você mudar a implementação interna mantendo o resultado, mas seu teste de Mock quebrar, você pode estar sofrendo de Acoplamento Excessivo. Tente tornar seus testes mais resilientes focando no comportamento final desejado. 🚀 🏁


⬅️ Capítulo Anterior | Próximo Capítulo ➡️