Opte por mockar classes que lidam com infraestrutura e que tornariam seu teste muito complicado. Por exemplo, relembre nosso gerador de nota fiscal...

Opte por mockar classes que lidam com infraestrutura e que tornariam seu teste muito complicado. Por exemplo, relembre nosso gerador de nota fiscal. A nota era persistida em um banco de dados e depois enviada para o SAP. Preparar tanto o banco quanto o SAP para receber o teste não é fácil. Portanto, simular a interação de ambas as classes é uma boa ideia. Use mocks também quando sua classe lida com interfaces. Em nossa versão final do gerador de nota fiscal, criamos a interface IAcaoAposGerarNota. Nesses casos, o mais simples talvez seja mockar a interface ao invés de criar uma implementação concreta “simples”, somente para o teste. Por outro lado, um ponto negativo do uso de mock objects é o alto acoplamento criado entre o código de teste e o código de produção. Já discutimos o conceito de encapsulamento no capítulo anterior: uma classe deve esconder a maneira na qual ela implementa determinada regra de negócio. Quando um teste faz uso de um mock, esse teste passa a ter uma “intimidade inapropriada” com a implementação; ele passa a saber quais métodos serão invocados, e como a classe deve reagir de acordo com o resultado. Veja o código de produção e teste abaixo, responsável por calcular o imposto de um pedido, de acordo com uma tabela de preços:

a) O teste DeveCalcularImpostoParaPedidosSuperioresA2000Reais sabe exatamente qual método será invocado no código de produção.
b) Quanto maior o uso de mocks, mais delicado e frágil o teste fica.
c) Muitos desenvolvedores acabam "testando o mock" ao mockar todos os objetos nos testes.
d) O uso de mock objects é recomendado em todas as situações de teste.