Unit Test Geruch

Ich versuche, meine Unit-Tests von ArcGIS zu ändern, und fangen mit Mocks (ich benutze Rhino).
Als ich anfing, die Tests zu schreiben, bemerkte ich, dass ich anfangen musste, eine Menge Objekte zu verspotten, und viele Methoden anwendete, damit auch nur ein Test bestanden wurde.
Zum Beispiel - mein Controller bekommt zuerst ein RelationshipClass (so ich brauche die IWorkspace und die zurück IRelationshipClass Stub), dann bekommt auch einen IFeature (a Stummel) und schließlich ruft stubRelClass.GetRelatedObjects(stubFeature), ein ISet anderen IFeatures zurückzukehren.Unit Test Geruch

Ist es normal, so viele Objekte und Methoden zu stubben, nur um sie passieren zu lassen? Ich fühle auch wie ich muss wirklich über den Code (yeah - ich weiß, ich hätte die Tests zuerst geschrieben werden, ich versuche immer noch dies), um herauszufinden, was als nächstes auszugeben, und was ich zurückgeben sollte .

Ich habe auch Probleme mit Mocking com-Klassen, die mehr als eine Schnittstelle implementieren. Im Produktionscode I QI sie zwischen den Schnittstellen. Wie kann ich einen Mock erstellen, der beide Schnittstellen zur Laufzeit implementiert?

Quelle

2009-06-29 Noam Gal

Abhängig von Ihrer Injektionskette, ja, manchmal müssen Sie viele Objekte verspotten. Wenn Sie jedoch mehrere Ebenen tief gehen, kann dies auf einen Konstruktionsfehler hindeuten - Objekte, die auf Daten basieren, die drei Ebenen unterhalb Ihrer API sind, sind möglicherweise nicht lose gekoppelt. Sie sollten in der Lage sein, die Kette im Keim zu ersticken, indem Sie einfach irgendwann ein falsches Objekt zurückgeben, das die notwendigen Eigenschaften hat, die die Schicht, an der Sie testen, benötigt.

Sie sollten auch in der Lage sein, die meisten Ihrer Spott in einer [SetUp] Methode zu tun und dann jeden Test nur ein oder zwei Dinge ändern.

Für das Spotten mehrerer Schnittstellen hat Rhino das Konzept eines MultiMocks. Ich glaube, die Syntax sind Sie nach ist:

var mock = 
    MockRepository.DynamicMultiMock<MyType>(
       typeof(Interface1), 
       typeof(Interface2), 
       ....);

Quelle

2009-06-29 06:30:18 womp

Über ein Objekt einzuführen, die die tiefen Ebenen schneidet - es wird „retten“ mich von ein paar mehr Objekte spöttischen (da diese Aufgabe für sie decken), aber ich würde müssen noch über die verspotten gleiche Menge an Methoden, oder? Oder mache ich das falsch? –

Der Punkt besteht nicht darin, "dich zu retten" davor, mehr Objekte zu verspotten. Der Punkt ist, dass der Test versucht, Ihnen zu sagen, dass da ein fehlendes Konzept drin ist, deshalb ist es so kompliziert. –

Für mich ist es wie untestable Code klingt, der ein Geruch :-(

ist empfehle ich http://misko.hevery.com/code-reviewers-guide/ lesen würde Der Autor ist Trainer verantwortlich für den Unterricht Google. Entwickler im Testbereich Im Artikel zeigt er, wie man testbaren und nicht testbaren Code schreiben kann

Weitere empfohlene Lektüre: Clean Code (Robert C. Martin) - Hauptfokus auf das Schreiben sauber (das entspricht testbar) Code Effektiv mit Legacy-Code arbeiten (Michael Feather) - zeigt Wege, wie ungeprüfter und nicht testbarer Code unter Kontrolle gebracht werden kann.

Quelle

2009-06-29 06:30:41 jens

und wenn es Ihnen nichts ausmacht eine kurze Werbepause ... http://www.mockobjects.com/book –

Es könnte ein Zeichen für eine hohe Kopplung sein - was wiederum bedeutet, dass die Abhängigkeiten reduziert werden müssen (was das Design und die Testbarkeit verbessern wird). Als grobe Richtlinie sollte ein Objekt maximal 4 bis 6 Mitarbeiter haben. Alles darüber würde meinen Alarm auslösen.

How are Mocks meant to be used?

Quelle

2009-06-29 06:42:25 Gishu

Antwort

Verwandte Themen