Ich habe Moq benutzt, um meine Repositories nachzuahmen. Jedoch hat jemand kürzlich gesagt, dass sie es vorziehen, hartcodierte Testimplementierungen ihrer Repository-Schnittstellen zu erstellen.
Was sind die Vor- und Nachteile der einzelnen Ansätze?
Bearbeiten: klärte die Bedeutung des Repositories mit einem Link zu Fowler.
Ich sehe im Allgemeinen zwei Szenarien mit Repositories. Ich frage nach etwas, und ich bekomme es, oder ich frage nach etwas, und es ist nicht da.
Wenn Sie sich über Ihr Repository lustig machen, bedeutet dies, dass das zu testende System (SUT) Ihr Repository verwendet. Daher möchten Sie im Allgemeinen testen, ob sich Ihr SUT korrekt verhält, wenn ihm ein Objekt aus dem Repository zugewiesen wird. Und Sie möchten auch testen, dass es die Situation richtig behandelt, wenn Sie erwarten, etwas zurückzubekommen und nicht, oder nicht sicher sind, ob Sie etwas zurückbekommen.
Hartcodierte Testdoppelwerte sind in Ordnung, wenn Sie Integrationstests durchführen. Angenommen, Sie möchten ein Objekt speichern und dann zurückbekommen. Dies testet jedoch die Interaktion zweier Objekte, nicht nur das Verhalten des SUT. Sie sind zwei verschiedene Dinge. Wenn Sie mit der Programmierung von Fake-Repositories beginnen, benötigen Sie auch Komponententests für diese, ansonsten basieren Sie auf Erfolg und Misserfolg Ihres Codes auf nicht getestetem Code.
Das ist meine Meinung zu Mocking vs. Test-Doppel.
SCNR:
"Sie nennen sich selbst ein Repository? Ich habe Streichholzschachteln mit mehr Kapazität gesehen!"
Ich nehme an, dass Sie unter "Repository" ein DAO verstehen; wenn nicht, dann gilt diese Antwort nicht.
In letzter Zeit mache ich "im Speicher" "Schein" - (oder Test-) Implementierungen meiner DAO, die im Grunde genommen aus Daten (einer Liste, Karte, etc.) arbeiten, die in den Konstruktor des Scheinwerfers übertragen werden. Auf diese Weise kann die Komponententestklasse beliebige Daten, die sie für den Test benötigt, einwerfen, ändern usw., ohne dass alle Komponententests, die auf dem DAO "im Speicher" arbeiten, so codiert werden müssen, dass dieselben Testdaten verwendet werden.
Ein Plus, das ich in diesem Ansatz sehe, ist, dass, wenn ich ein Dutzend Komponententests habe, die das gleiche DAO für ihren Test verwenden müssen (um beispielsweise in die getestete Klasse zu injizieren), muss ich mich nicht daran erinnern alle Details der Testdaten jedes Mal (wie wenn der "Schein" fest codiert wäre) - der Komponententest erstellt die Testdaten selbst. Auf der anderen Seite bedeutet dies, dass jeder Komponententest ein paar Zeilen für die Erstellung und Verkabelung seiner Testdaten ausgeben muss. aber das ist ein kleiner Nachteil für mich.
Ein Codebeispiel:
%Vor%Tags und Links testing repository-pattern mocking