Mocking ein Objekt mit Moq, mit Ninject, wenn dabei UnitTesting

Ich habe Probleme mit Moq in ein UnitTesting-Projekt mit Ninject.

Zunächst ein paar Zeilen über meine Lösung. Es enthält mehrere Projekte (BussinesLogic, DAL, Infrastruktur...). Mein Ziel ist es, UnitTest die Logik, die ich verwende in BussinessLogic Projekt.
Die Lösung ist im Grunde für einen windows-Dienst, aber ich habe in der Logik, damit es ausgeführt werden kann Stand-alone. Ich bin mit Ninject und ich angeben Wetter-ich will das ProductionModule oder die TestingModule (windows-Dienst verwendet ProductionModule, Konsole-app nutzt TestingModule)

Bin ich mit einem factory-pattern, um zu bekommen, ninject-kernel, wenn ich es brauche in meiner Anwendung.

Meine TestingModule erbt von NinjectModule wo ich überschreiben Sie die Methode Load() und da ich die Bindung. Zum Beispiel:

Bind<IStorageManager>().To<StubStorageManager>();

Habe ich die StubStorageManager aber es ist leer. Es enthält nur die Deklaration der Methoden aus IStorageManager.

Die Sache, die ich tun möchte, ist (in laymans terms):
Erstellen Sie ein unitTest, wo ich erstellen Sie eine neue kernel-Angabe der TestingModule, wie es s-parameter. Dann würde ich gern ein mock-Objekt (sagen wir mal ein mock IStorageManager) storageManagerMock. Einige Methode in IStorageManager gibt eine messageObject, so würde ich Sie wahrscheinlich benötigen, um zu spotten, dass auch aufgrund der bussiness-Logik ist, etwas zu tun, basierend auf, dass messageObject. Also ich würde gerne irgendwie in den Eigenschaften festlegen, das message-Objekt und rufen Sie dann einige businessLogic-Methode auf, damit ich sehen kann, ob die Logik richtig funktioniert.

Ich hoffe, ich habe nicht kompliziert es zu viel.

Bitte Geduld mit mir, ich bin völlig neu mocking und dependency injection, aber bin bereit zu lernen.

InformationsquelleAutor Alex Dee | 2011-04-29
  1. 12

    Ich bezweifle, dass Sie wirklich wollen, werden unter Verwendung von Ninject in Ihren tests. Der springende Punkt bei der Verwendung von ninject ist, dass man entkoppeln alles. Sie wollen auch, um zu versuchen und halten alles abgekoppelt von der Abhängigkeit container selbst, wenn möglich. Übergeben Sie es in, wenn Sie müssen, oder pass in den Fabriken, die das gewünschte Objekt und haben den container übergeben, in der Fabrik.

    Ich vermute, Sie wollen wahrscheinlich etwas wie das hier tun:

    public void ATest(){
   //create a mock StorageManager
   var managerMock = new Mock<IStorageManager>();
   //create a mock MessageObject to be used by business logic
   var messageObjectMock = new Mock<MessageObject>();

   //have the storage manager return the mock message when required
   managerMock.Setup(x => x.GetMessageObject()).Returns(messageObjectMock.Object);
   //set up message expectations
   messageObjectMock.Setup(x => x.ThisValueExpected).Returns(10);
   messageObjectMock.Setup(x => x.ThisFunctionShouldBeCalled()).Verifiable("Function not called.");

   //thing to test
   BusinessLogicObject blo = new BusinessLogicObject(managerMock.Object);
   blo.DoTheThingImTesting();

   //make sure the business logic called the expected function, or do whatever check you need...
   messageObjectMock.Verify();
 }
    • Das ist genau, was ich tun wollte. Ok, also mit einem DI-container in test schlecht ist nehme ich es? Warum ist das so? Ich dachte, es zu benutzen, könnte es vereinfachen meine tests so i dont haben, um zu schreiben: var p = new Program(new StubHealthMonitor(), storageManagerMock, new LogManager(), new StubConfigurationManager()); ich im Grunde dachte, ich würde den DI-container kümmert sich um alle Dinge, die gar nicht direkt mit diesem test, aber die eine Sache, erfordert der test, ich konnte angeben, auf meine eigene, über Moq.
    • Ich bin mir nicht sicher, ob ich würde gehen so weit zu sagen, mit DI in der Prüfung ist "bad". Sub-optimal-aber nur vielleicht 😉 die Sache, Die Sie tun wollen mit Ihren tests ist zu entfernen, wie viel externe 'Sachen' wie möglich und verwenden Sie nur, was Sie testen. Wenn Sie DI " in den tests haben Sie nun das hinzugefügte Komplexität der dependency injection. An diesem Punkt sind Sie in der Wirkung testen Ihrer DI sowie die Sache unter test. Sie könnten in der Lage sein, einen Fall für die Verwendung von DI in Ihre tests, obwohl ich noch nie brauchte noch. Bei der Verwendung von DI nichts sollte eng gekoppelt werden, um alles - einschließlich DI-so sollten Sie nicht brauchen.
    InformationsquelleAutor Russell Troywest
Schreibe einen Kommentar