Was sind die Schlüsselfaktoren bei der Wahl eines Mocking Frameworks?

Ich möchte mit Objekten in meinen Unit-Tests beginnen. Es scheint Unmengen guter Spott-Frameworks zu geben.

1. Haben die verschiedenen Frameworks unterschiedliche Zielgruppen?
2. Welche Faktoren sollten bei der Auswahl des für meine Situation geeigneten Rahmens berücksichtigt werden?

Haben die verschiedenen Frameworks unterschiedliche Zielgruppen?

Ja. Mit einigen Frameworks wie Microsoft Moles , TypeMock Isolator und JustMock können Sie so gut wie alles verspotten. Diese Spott-Tools sind im Allgemeinen besser für Entwickler, die sie in vorhandenem Legacy-Code verwenden möchten, da es möglicherweise nicht möglich ist, ein solches Design in ein prüfbareres umzuwandeln. *

Traditionell bedeutet testbares Design, dass die Codebasis Schnittstellen, abstrakte Klassen, virtuelle Methoden, nicht versiegelte Klassen usw. großzügig nutzen muss. Daher funktionieren traditionelle Mocking-Frameworks wie Moq und RhinoMocks gut mit Code, der mit Test Driven Development, Dependency Injection und entwickelt wurde andere solche Konzepte. Übrigens würde ich die Verwendung von Dependency Injection sehr empfehlen, da Sie viel mehr als nur testbaren Code, sondern auch mehr wartbaren Code erhalten.

Welche Faktoren sollten bei der Auswahl des für meine Situation geeigneten Rahmens berücksichtigt werden?

• Entwicklungsaktivität. Tools wie Moq und RhinoMocks sind sehr aktiv und beliebt und daher auf dem neuesten Stand.
• Open Source Vs. Kommerziell . Betrachten Sie die verschiedenen Vor- und Nachteile, die für diesen Vergleich typisch sind. Kosten, Support, etc ...
• Reife. Wie neu ist das Tool. Befindet es sich in der Beta-Version (wie Microsoft Moles) oder hatte es mehrere stabile Releases? Zum Beispiel mag ich Moles für Legacy-Code, aber es gibt einige Fehler, die behoben werden müssen, und es wird eine Weile dauern, bis sie behoben werden (nächste Veröffentlichung November 2011).
• Dokumentation. Es gibt mehrere Bücher und Blogs, in denen Unit-Tests, Verspottungen, automatische Verspottungen usw. behandelt werden. Wie gut ist außerdem die Dokumentation des Tools?
• Syntax . Jedes Werkzeug hat seine eigene Art, dasselbe zu sagen. Finden Sie heraus, welches besser zu Ihnen passt.
• Geschwindigkeit . Tools, die die CLR-Profilerstellung verwenden (TypeMock, Moles, JustMock), können viel langsamer sein als herkömmliche Tools (Moq, RhinoMocks). Diese Geschwindigkeitsstrafe kann ein Problem sein, da Sie viele Komponententests absolvieren. Als Faustregel gilt: Wenn ein Test länger als 1/10 Sekunde dauert, ist er zu langsam.
• Community-Unterstützung . Schreiben andere Entwickler andere Tools, die das Spott-Tool ergänzen (oder ergänzen)? Es gibt ein Moq.Contrib- Projekt, das Moq eine Auto-Mocking-Funktion hinzufügt (wodurch die Testschreibzeit verkürzt wird). Besser noch, es gibt AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, die auch Auto-Mocking und die Erstellung anonymer Variablen ermöglichen.

^{* Unter Effektiv mit Legacy-Code arbeiten erfahren Sie , wie Sie Code ohne Tests langsam in Code umwandeln, der mit herkömmlichen Test- (und Spott-) Tools verwendet werden kann.}

Das Moq-Tutorial enthält gleich zu Beginn einen Abschnitt zu Hintergrund, Philosophie und Kontroversen, in dem dies anhand einiger spezifischer Tools erläutert wird: TypeMock Isolator, RhinoMocks und Moq. Es wurde geschrieben, um Moq zu erklären, ist also natürlich etwas verzerrt, aber ich fand es ziemlich hilfreich für mich, wenn ich versuchte, einige der Unterschiede in den Spott-Frameworks zu verstehen.

Ich fand die Antworten auf diesen SO-Thread in C # Mocking Frameworks auch nützlich. Die meisten beziehen sich nur auf ein Mocking Framework, das der Benutzer wirklich nützlich findet, aber es gibt eine Antwort von HaraldV , in der Proxy-basierte Mocks und Profiler-basierte Mocks erörtert werden.

Ich konnte auch online eine Vergleichstabelle finden. Beachten Sie, dass es aus dem Jahr 2009 stammt, daher bin ich mir nicht sicher, ob es auf dem neuesten Stand ist. Es gibt mindestens einen Kommentar, der besagt, dass die Informationen zu TypeMock und Rückrufen veraltet sind. Das Diagramm kann jedoch hilfreich sein, um Probleme zu berücksichtigen, auch wenn Sie noch einige Vorbereitungen treffen müssen, um den aktuellen Status zu ermitteln: RhinoMocks, Moq, NMock, und TypeMock Vergleichstabelle

Auf Google Code gibt es ein Projekt mit Testfällen in mehreren Verspottungsframeworks zum einfachen Codevergleich: Verspottungsframeworks vergleichen

1. Benutzerfreundlichkeit. Einige der Frameworks haben fortgeschrittenere Gebrauchssprachen. Zum Beispiel erlaubt MOQ die Verwendung von Lambdas, um Erwartungen zu kodieren. Einige ältere Bibliotheken unterstützen dies nicht.
2. Geschwindigkeit. Jeder Komponententest sollte schnell sein, damit Ihre gesamte Bibliothek nicht stundenlang ausgeführt wird. Einige Mock-Frameworks haben statisch erzeugte Mocks, was schnell ist. Andere Frameworks generieren zur Laufzeit dynamisch Code, was langsamer ist.
3. Unterstützung. Sie möchten ein Framework, das aktiv mit Fixes unterstützt und aktualisiert wird, um neue Versionen von .NET zu unterstützen, sobald diese veröffentlicht werden.
4. Leistung. Die meisten der von mir untersuchten Spott-Frameworks sind in Bezug auf die Leistung ungefähr gleich. Es gibt eine bemerkenswerte Ausnahme. Microsoft Moles ermöglicht das Verspotten von "nicht virtuellen / statischen Methoden in versiegelten Typen". Soweit ich weiß, unterstützt dies kein anderer spöttischer Rahmen.

In meinem Team haben wir uns für Microsoft Moles entschieden . Es gewinnt signifikant auf # 2, # 3 und # 4, obwohl es weniger idiomatisch als die meisten Alternativen ist und auf # 1 am unteren Ende liegt.