none
Testes Unitários com Injeção de Dependencias e Moq RRS feed

  • Pergunta

  • Primeiramente, bom dia.

    Pessoal, é o seguinte, tenho um service para testar, nele eu passo por parâmetro um objeto repositório que faz a conexão com o banco. O problema todo é quando tenho que simular este método para em vez de ficar buscando no banco, retorne um objeto do modo que eu desejo.

    Exemplo:

    public class Service{
    
     private IRepository repository;
    
     public Service(IRepository repository){
        this.repository = repository;
     }
    
     public IEnumerable<object> BuscarCoisas(){
          return repository.Buscar();
     }
    
    }
    
    // Método de Teste
    
    public void Testar(){
    
      var repository = new Mock<IRepository>();
      //Simulo um novo objeto para dar um 'override' no método original.
      repository.Setup(r => r.Buscar()).Returns(new object());
    
      var service = new Mock<IService>();
      service.buscar();
    
    }
    
    

    Como eu passaria esse objeto simulado do repositório para o meu service ? Pois com construtor não é possível através de interfaces.

    Se eu utilizar uma instância da classe concreta (tipo var service = new Service(repository)) isso quebra minha injeção de dependencias.

    Existe alguma saída ?

    quarta-feira, 22 de janeiro de 2014 13:18

Todas as Respostas

  • var a = new Mock<IRepository>();
    var employee = new Employee();
    a.Setup(s => s.Save(employee)).Returns(true).Verifiable();
    var result = new EmployeeService(a.Object).SaveEmployeeData(employee, true);
    Assert.IsTrue(result);
    Será que ajuda?

    Fulvio Cezar Canducci Dias

    quarta-feira, 22 de janeiro de 2014 15:20
  • Olá Fúlvio!

    No momento estou fazendo desse jeito, instanciando a classe concreta do service, porém, eu queria que o mesmo não dependesse dela e sim da abstração.

    Uma dúvida, para que serve o Verifiable ?

    quarta-feira, 22 de janeiro de 2014 16:19
  • Olá Fúlvio!

    No momento estou fazendo desse jeito, instanciando a classe concreta do service, porém, eu queria que o mesmo não dependesse dela e sim da abstração.

    Uma dúvida, para que serve o Verifiable ?

    No caso é só teste não é ???!

    Resposta:

    Link: http://stackoverflow.com/questions/15360685/moq-is-it-possible-to-specify-in-a-setup-the-verify-criteria-e-g-times-calle (fonte)

    Inglês

    Personally I prefer calling verify individually to confirm the required behavior of the caller, the.Verifiable() and .Verify() are shortcuts that are less strict (they just check the method was called one or more times) however if you know your code should only call a method once, put the verify in at the end to confirm it.

    I started doing that after a code merge resulted in a method being called twice, the test still passed since it was called at least once but it also meant that something else happened multiple times which shouldn't have!

    Tradução:

    Pessoalmente eu prefiro chamar verificar individualmente para confirmar o comportamento necessário do chamador, o. Verificável () e. Verifique () são atalhos que são menos rigoroso (que basta verificar o método foi chamado uma ou mais vezes), no entanto, se você sabe o seu código só deve chamar um método uma vez, colocar a verificar no final para confirmar. 

    Eu comecei a fazer isso depois de uma mesclagem de código resultou em um método que está sendo chamado duas vezes, o teste ainda passou desde que foi chamado, pelo menos uma vez, mas também significava que algo mais aconteceu várias vezes que não deve ter!


    Fulvio Cezar Canducci Dias


    quarta-feira, 22 de janeiro de 2014 18:13