Há algum tempo, li em uma resposta do Stack Overflow que não consigo encontrar, uma frase que explicava que você deveria testar APIs públicas e o autor disse que deveria testar interfaces. O autor também explicou que, se uma implementação de método fosse alterada, não seria necessário modificar o caso de teste, pois isso quebraria o contrato que garantiria que o sistema em teste funcionasse. Em outras palavras, um teste deve falhar se o método não funcionar, mas não porque a implementação foi alterada.
Isso chamou minha atenção quando falamos de zombaria. Como a zombaria depende muito das chamadas de expectativa das dependências do sistema em teste, as zombarias são fortemente acopladas à implementação e não à interface.
Ao pesquisar mock versus stub , vários artigos concordam que stubs devem ser usados em vez de zombarias, pois não dependem das expectativas das dependências, o que significa que o teste não precisa ter conhecimento do sistema subjacente na implementação do teste.
Minhas perguntas seriam:
- As zombarias violam o princípio de aberto / fechado?
- Há algo faltando no argumento a favor dos stubs no último parágrafo, que torna os stubs não tão bons contra os mocks?
- Em caso afirmativo, quando seria um bom caso de uso para zombar e quando seria um bom caso de uso para usar stubs?
Since mocking relays heavily on expectation calls from system under test's dependencies...
Eu acho que é aqui que você está dando errado. Um mock é uma representação artificial de um sistema externo. Ele não representa o sistema externo de forma alguma, exceto na medida em que simula o sistema externo de forma que permita a execução de testes contra códigos com dependências no referido sistema externo. Você ainda precisará de testes de integração para provar que seu código funciona com o sistema real, sem desbloqueio.