NMOCK2.0 - Como arrancar uma chamada de interface?

Question

Eu tenho uma API de classe que possui cobertura de código completa e usa DI para zombar de toda a lógica na função de classe principal (Job.run), que faz todo o trabalho.

Encontrei um bug na produção em que não estamos validação em um dos campos de entrada de dados.

Então, eu adicionei uma função de stub chamada validatefoo () ... escrevi um teste de unidade contra essa função para esperar um JobFailedException, executou o teste - ele falhou obviamente porque essa função estava vazia. Adicionei a lógica de validação e agora o teste passa.

Ótimo, agora sabemos que a validação funciona. O problema é - como escrevo o teste para garantir que o validatefoo () seja realmente chamado Inside Job.run ()? ValidateFoo () é um método privado da classe de trabalho - então não é uma interface ...

Existe alguma maneira de fazer isso com o nmock2.0? Eu sei que o TypeMock suporta falsificações de tipos de interface. Mas mudar as Libs simuladas agora não é uma opção. Neste ponto, se o NMOCK não puder apoiá -lo, simplesmente adicionarei o método ValidateFoo () para o método run () e testar as coisas manualmente - o que obviamente preferiria não fazer considerando o meu método de trabalho.run () 100% de cobertura agora. Algum conselho? Muito obrigado, é apreciado.

Editar: a outra opção que tenho em mente é apenas criar um teste de integração para o meu trabalho.RUN FUNCIONALIDADE (Injetando a ela verdadeiros implementações dos objetos compostos em vez de zombares). Vou dar um mau valor de entrada para esse campo e, em seguida, validar que o trabalho falhou. Isso funciona e cobre meu teste - mas não é realmente um teste de unidade, mas um teste de integração que testa uma unidade de funcionalidade .... hmm ..

Edit2: Existe alguma maneira de fazer tihs? Alguém tem ideias? Talvez o TypeMock - ou um design melhor?

Answer 1

A versão atual do nmock2 Pode zombar dos tipos de concreto (não me lembro exatamente de qual versão eles adicionaram isso, mas estamos usando a versão 2.1) usando a sintaxe principalmente familiar:

Job job = mockery.NewMock<Job>(MockStyle.Transparent);
Stub.On(job).Method("ValidateFoo").Will(Return.Value(true));

MockStyle.Transparent Especifica que qualquer coisa que você não esboço ou espere deve ser tratada pela implementação subjacente - para que você possa esgotar e definir expectativas para os métodos em uma instância que está testando.

No entanto, você só pode extrair e definir expectativas em métodos públicos (e propriedades), que também devem ser virtuais ou abstratos. Portanto, para evitar confiar nos testes de integração, você tem duas opções:

• Faço Job.ValidateFoo() público e virtual.
• Extrair a lógica de validação para uma nova classe e injetar uma instância em Job.

Answer 2

Como todos os privados são chamados por métodos públicos (a menos que dependem da execução do tempo de execução da reflexão), esses privados estão sendo executados por métodos públicos. Esses métodos privados estão causando alterações no objeto, além de simplesmente executar o código, como definir campos de classe ou chamar outros objetos. Eu encontraria uma maneira de obter esses "resultados" de chamar o método privado. (Ou zombando das coisas que não devem ser executadas nos métodos privados.)

Não consigo ver a classe em teste. Outro problema que pode estar pressionando você a querer acesso aos métodos privados é que é uma classe super grande com um monte de funcionalidade privada. Essas classes podem precisar ser divididas em classes menores, e algumas dessas privadas podem se transformar em públicos mais simples.