Wie kann ich simulieren Sie eine Schnittstelle mit Moq oder NInject-Kernel Spott

Gibt es wenig oder keinen Vorteil der Verwendung von dependency injection in unit-Tests. Dependency injection hilft Ihnen bei der Erstellung lose gekoppelter Komponenten und lose gekoppelte Komponenten sind leichter zu testen, das Wars.

Also, wenn Sie testen möchten-service, nur Attrappen, es Abhängigkeiten und übergeben Sie an, dass der service wie gewohnt (keine Notwendigkeit der Beteiligung von IOC-container hier, ich kann sich kaum vorstellen, dass Sie, müssen Sie einige features von IOC-Containern - wie kontextuelle Bindung, abfangen etc. - inside unit-test).

Wenn Sie möchten, dass Ihre ApplicationService um einfach zu testen, es sollte Aussehen wie:

public class ApplicationService: IApplicationService
{
    private readonly IEntityFrameworkRepo repo; 

    //dependency passed by constructor
    public ApplicationService(IEntityFrameworkRepo repo)
    {
         this.repo = repo;
    }

    //save to db when DTO is eligible
    public ApplicationDto Add(ApplicationDto dto)
    {
         //some business rule
         if(dto.Id > 0 && dto.Name.Contains(string.Empty)){
              //add to dbcontext and commit
         }else{
              throw new NotEligibleException();
         } 
    }   
}

Hier die Abhängigkeit übergeben wird durch den Konstruktor. In Ihrer Anwendung code, den Sie zusammen mit einem IOC-container zu machen constructor injection (IOC-container sind verantwortlich für das erstellen von Instanzen von IEntityFrameworkRepo).

Aber im unit-test, Sie können nur passieren Instanz einer Implementierung von IEntityFrameworkRepo auf Ihrem eigenen.

ApplicationDto

Solange ApplicationDto Sie einige Objekt, das durch die von hand angelegt, ich kann auch direkt im unit-testen (erstellen von Instanzen von hand). Ansonsten werde ich haben, um wickeln Sie es nach Schnittstelle wie IApplicationDto, um der Lage sein, zu verhöhnen, als es mit Moq.

public class ApplicationDto{
     public int Id {get; set;}
     public string Name {get; set;}
}

Hier ist, wie könnte unit-test wie folgt Aussehen:

In unit-test-ich werde verspottet Implementierung IApplicationRepo, weil ich nicht konfigurieren möchten, z.B. Datenbank-verbindungen, web services etc. und meine primäre Absicht ist, zu testen, die ApplicationService nicht die zugrunde liegenden repository. Ein weiterer Vorteil ist, dass der test lauffähig ohne spezielle Konfiguration für verschiedene Maschinen. Zum mockup einige db-repository, die ich nutzen kann z.B. List.

[Test(Description = "Test If can successfully add application")]
public void CanAddApplicationIfEligible()
{
    var repo = GetRepo();
    var appService = new ApplicationService(repo);       
    var testAppDto = new ApplicationDto() { Id = 155, Name = "My Name" };

    var currentItems = repo.ApplicationDtos.Count();

    appService.Add(testAppDto);

    Assert.AreEqual(currentItems + 1, repo.ApplicationDtos.Count());
    var justAdded = repo.ApplicationsDto.Where(x=> x.Id = 155).FirstOrDefault();
    Assert.IsNotNull(justAdded);
    ///....
}

private static IEntityFrameworkRepo GetRepo{
    //create a mock repository
    var listRepo = new List<ApplicationDto>{
                         new ApplicationDto {Id=1, Name="MyName"}               
                   };

    var repo = new Mock<IEntityFrameworkRepo>();

    //setup the methods you know you will need for testing

    //returns initialzed list instead of DB queryable like in real impl.
    repo.Setup(x => x.ApplicationDtos)
        .Returns<IQueryable<ApplicationDto>>(x=> listRepo);

    //adds an instance of ApplicationDto to list
    repo.Setup(x => x.Add(It.IsAny<ApplicationDto>())
        .Callback<ApplicationDto>(a=> listRepo.Add(a));
    return repo.Object;
}

Hinweis:

Gab es realeased ein ninject.mockingkernel Erweiterung. Der Ansatz, beschrieben in Beispiel auf wiki können Sie Ihre unit-test-code etwas aufgeräumter, aber der Ansatz beschrieben, es ist definitiv nicht depencdency Einspritzung (es ist der service-locator).