Wenn zu erwarten ist und wann Stub?

Question

Ich benutze NMock2, und ich habe die folgenden NMock Klassen entworfen, um einige gemeinsame mock Rahmen Konzepte darstellen:

• Expect: dies gibt an, was eine verspottet Methode zurückgeben soll und sagt, dass der Anruf erfolgen muss oder der Test fehlschlägt (wenn sie von einem Anruf begleitet VerifyAllExpectationsHaveBeenMet())

.

• Stub: dies gibt an, was eine verspottet Methode zurückgeben soll, kann aber ein Test nicht fehlschlagen

.

Also welche soll ich tun, wenn?

Answer 1

Viele spöttischen Frameworks bringen die Konzepte von Mocks und Stubs näher und näher zusammen zu dem Punkt, dass sie funktionell fast die gleiche betrachtet werden können. jedoch aus konzeptioneller Sicht ich in der Regel versuchen, dieser Konvention zu folgen:

• Mock :. Nur wenn Sie explizit versuchen, das Verhalten des Objekts unter Test, um zu überprüfen (das heißt Ihr Test sagen, dass dieses Objekt muss das Objekt nennen)
• Stub : Wenn Sie versuchen, einige Funktionen / Verhalten zu testen, aber in Ordnung zu bringen, dass die Arbeit Sie auf einige externe Objekte verlassen müssen (dh Ihr Test sagt, dass dieses Objekt etwas tun muss , aber als Nebenwirkung kann es das Objekt nennen)

Dies wird deutlicher, wenn Sie sicherstellen, dass jede Ihrer Unit-Tests nur Test eine Sache. Sicher, wenn Sie versuchen, alles in einem Test zu testen, dann könnten Sie auch alles erwarten. Aber nur die Dinge erwarten, dass bestimmte Unit-Test ist die Überprüfung für Ihr Code ist viel klarer, weil man auf einen Blick sehen können, was der Zweck des Tests ist.

Ein weiterer Vorteil ist, dass Sie etwas von Veränderung isoliert sein würden und bessere Fehlermeldungen erhalten, wenn eine Änderung eine Pause verursacht. Mit anderen Worten, wenn Sie subtley Veränderung eines Teil Ihrer Implementierung, Ihr eher nur ein Testfall Bruch erhalten, die Ihnen genau zeigen, was kaputt ist, anstatt eine ganze Reihe von Tests zu brechen und nur Lärm erzeugt wird.

Bearbeiten : Es könnte klarer sein, basierend auf einem konstruiertes Beispiel, wo ein Rechner Objekt Audits alle Zugänge zu einer Datenbank (in Pseudo-Code) ...

public void CalculateShouldAddTwoNumbersCorrectly() {
    var auditDB = //Get mock object of Audit DB
    //Stub out the audit functionality...
    var calculator = new Calculator(auditDB);
    int result = calculator.Add(1, 2);
    //assert that result is 3
}

public void CalculateShouldAuditAddsToTheDatabase() {
    var auditDB = //Get mock object of Audit DB
    //Expect the audit functionality...
    var calculator = new Calculator(auditDB);
    int result = calculator.Add(1, 2);
    //verify that the audit was performed.
}

So im ersten Testfall testen wir die Funktionalität des Add Methode & ist es egal, ob ein Audit-Ereignis eintritt oder nicht, aber wir passieren zu wissen, dass der Rechner nicht mit trainiert eine AUDITDB Referenz so wir Stummel es nur uns ein Minimum an Funktionalität zu geben, unseren spezifischer Testfall zum Laufen zu bringen. Im zweiten Test sind wir speziell zu testen, dass, wenn Sie ein Add tun, geschieht das Überwachungsereignis, also hier nutzen wir die Erwartungen (Beachten Sie, dass wir nicht einmal egal, was das Ergebnis ist, denn das ist nicht das, was wir testen).

Ja könnte man die beiden Fälle miteinander kombinieren, und Erwartungen tun und behauptet, dass Ihr Ergebnis 3 ist, aber dann sind Testen Sie zwei Fälle, in einem Gerät zu testen. Dies würde Ihre Tests brüchiger machen (da es eine größere Oberfläche der Dinge, die den Test zu brechen ändern könnten) und weniger klar (da, wenn das fusionierte Test nicht seine nicht sofort klar, was das Problem .. ist die Zugabe nicht funktioniert, oder die Prüfung nicht?)

Answer 2

"Erwarten Sie Aktionen, Stub-Abfragen". Wenn der Anruf sollte den Zustand der Welt außerhalb des zu prüfenden Objekt ändern, es dann eine Erwartung machen - Sie kümmern uns um, wie es aufgerufen wird. Wenn es nur eine Abfrage, können Sie es einmal anrufen oder sechsmal, ohne den Zustand des Systems zu ändern, dann den Anruf Stummel.

Eine weitere Sache, feststellen, dass die Unterscheidung zwischen Stubs und Erwartungen, dh einzelne Anrufe, die nicht unbedingt ganze Objekte.

Answer 3

Nun ... IMHO kann es nicht einfacher sein: wenn Ihr Test Presenter über gewährleistet ist, wird Save nennen, erwarten ein. wenn Ihr Test ist Ihre Presenter über Gewährleistung Ausnahme ordnungsgemäß behandelt, wenn Speicher werfen, macht einen Stub.

Für weitere Informationen Besuche diesem Podcast von Hanselman und Osherove (Autor die Kunst der Unit Testing)