Ich verwende Dependency Injection, um Mocks für Code außerhalb meiner getesteten Klasse zu liefern. Ich finde, dass ich immer wieder den gleichen Code schreibe, um AuthProvider, ConfigurationManager usw., die in der Methode, die ich testen möchte, verwendet werden. Die Methode enthält Verzweigungen (wenn-dann-sonst) und deshalb habe ich mehrere Tests, um alle Ausführungspfade der Methode zu testen. Ich instanziiere jeden der Mocks mehrmals (einmal in jeder Testmethode), frage mich aber, ob das falsch ist. Auch ich setze Erwartungen für die Mocks und voreingestellten Antworten, die offensichtlich sind hauptsächlich Copy-Paste als solche Aufrufe als AuthProvider.Authenticate () in jeder Methode
aufgerufen werdenIn jeder Methode habe ich ein Mock-Repository eingerichtet und am Ende jeder Methode überprüfe ich das Mock-Repository. Sollte ich vielleicht eine Art Fabrik haben, um diese Mocks zu erstellen und ihre Erwartungen und Rückgabewerte festzulegen und wenn ja wie?
Für die Implementierung von Mocks verwende ich RhinoMocks.
"jede der Mocks mehrmals instanziieren" ist kein Problem. Objekte sind frei.
Seien Sie nur sicher, dass Sie die Scheinklassen nicht mehrmals definieren. Klassen sind teuer.
Sie haben auch eine "setUp" -Methode in einem Testfall, mit der Sie eine Fixture erstellen können, die von allen Tests verwendet wird. Ja, es ist für jeden Test neu aufgebaut. Nein, das ist kein Problem, es sei denn, es ist schmerzhaft langsam.
Wenn Sie NUnit verwenden, können Sie Instanzvariablen für Ihre Mocks verwenden und sie in Setup / Teardown zurücksetzen. Wenn Sie wiederholte Muster sehen, dann tun Sie, was Sie mit Produktionscode tun: Refactor und Extrahieren Sie Helper-Methoden, die ausdrücken, was Sie erreichen wollen (wenn es überhaupt keine Gemeinsamkeit gibt, dann gibt es ein Problem mit dem Design des Produktionscodes) / p>
Wenn es beim Setup erhebliche Unterschiede gibt, sollten Sie mehr als eine Testklasse für Ihre Produktionsklasse schreiben.
Denken Sie schließlich darüber nach, ob Ihre Produktionsklasse einfach zu beschäftigt ist und ein Teil des Verhaltens in ein Hilfsobjekt extrahiert werden sollte.
Hören Sie sich die Tests an!
Hier ist mein Take ..
Ich würde in diesem Fall keine Mock verwenden ... Ich würde eine Factory-Methode verwenden, um eine falsche Implementierung der Klasse zurückzugeben und die Abhängigkeitsinjektion zu verwenden, stattdessen diese Implementierung zu verwenden. Auf diese Weise würden Sie Doppelungen vermeiden und diese Implementierung wiederverwenden wieder n wieder ... wieder muss diese Fabrikimplementierung richtig refaktoriert werden, dh keine Vervielfältigung.
Mocks, ich denke, sollte verwendet werden, wenn Sie etwas dynamisches Verhalten testen .. etwas wie .. wurde eine Methode im Subsystem aufgerufen, wenn ich einige Aktionen auf SUT .. und später auf verify () zu verifizieren Dieses Verhalten ... Es gibt auch einen guten Artikel über Martin Folwer bliki Mock sind keine Stubs
Vielleicht möchten Sie den AAA-Testmodus verwenden, um mehrere Tests mit einem gemeinsamen Setup durchzuführen. Hier ist ein anständiges Beispiel. >
Aufnahme- und Wiedergabe-Frameworks wie EasyMock schlagen fehl, wenn Sie keine Erwartung für einen Schein-Aufruf setzen. Aber Frameworks wie Mockito zeichnen einfach alle Anrufe auf und lassen nur die wichtigen überprüfen. Sie müssen also nicht auf alle Methoden in allen Tests eine Erwartungshaltung setzen.
Und zurück zu Ihrem Problem, Mocks in jeder Testmethode zu instanziieren, gibt es einen besseren Weg als die Methode setUp (). Mockito bietet eine @Mock Annotation. So deklarieren Sie Ihre Variablen (als Felder) wie: @Mock Repository repositoryMock
und rufen Sie initMocks () in setUp () auf. Alle angemeldeten Mock-Objekte sind in Ihren Tests automatisch verfügbar, ohne explizit Mocks zu erstellen.
Tags und Links unit-testing dependency-injection mocking rhino-mocks