Frage

Nach mehreren Jahren, in denen die schlechte Praxis von 'Architects' an meinem Arbeitsplatz übergeben wurde und dachte, dass es einen besseren Weg geben muss, habe ich mich kürzlich in TDD und DDD gelesen, und ich denke, die Prinzipien und Praktiken wären ein Großartige Passform für die Komplexität der Software, die wir schreiben.

Viele der TDD -Proben, die ich gesehen habe, haben jedoch eine Methode auf dem Domänenobjekt aufgerufen und dann die Eigenschaften des Objekts testen, um das korrekte Verhalten sicherzustellen.

Andererseits befürworten mehrere angesehene Menschen in der Branche (Greg Young am deutlichsten, so mit seinen Gesprächen über CQRs) jedes Domänenobjekt vollständig, indem sie alle „Getter“ entfernen.

Meine Frage ist daher: Wie testet man die Funktionalität eines Domänenobjekts, wenn es verboten ist, seinen Zustand abzurufen?

Ich glaube, mir fehlt etwas Grundlegendes. Bitte nennen Sie mich einen Idioten und erleuchten Sie mich - jede Anleitung wäre sehr geschätzt.

War es hilfreich?

Lösung

Was Sie beschreiben, ist Zustandsüberprüfung wobei Sie im Zustand des Domain -Objekts geltend machen. Es gibt einen Zweig von TDD, der genannt wird Verhaltensüberprüfung Das verwendet Scheinobjekte.

Mit der Verhaltensüberprüfung können Sie angeben, welche Methoden aufgerufen werden sollten und ob Sie möchten, welche Methoden nicht aufgerufen werden.

Schauen Sie sich diesen Artikel von Martin Fowler an, um weitere Informationen zu erhalten: Mocks sind keine Stummel.

Andere Tipps

Ok, diese Antwort ist ein Jahr zu spät ;-)

Wenn Sie jedoch CQRS -Modelle testen möchten, können Sie Aussagen über die Ereignisse der gefeuerten Domänen anstelle von Behauptungen über den Entitätszustand vornehmen.

zB, wenn Sie testen möchten, ob anrufen: customer.rename ("foo") führt zu dem richtigen Verhalten.

Anstatt zu testen, ob Customer.name gleich "foo" ist, testen Sie lieber, ob ein ausstehender CustomErRename -Ereignis mit dem Wert "Foo" in Ihrem anhängigen Event -Shop vorhanden ist. (In Ihrer UOW oder in Ihrer Entitätsereignisliste je nach Implementierung)

Wenn Sie wirklich so weit gehen, das Abruf des Staates zu verbieten, werden Sie sich auf Verhaltenstests beschränken, wahrscheinlich durch einen spöttischen Rahmen wie Typemock, der die Macht hat, das Verhalten Ihres Objekts zu verfolgen. Wenn Sie in der Lage sind, reine BDD zu erledigen, können Sie theoretisch die Richtigkeit Ihres gesamten Systems behaupten, nur durch die Art und Weise, wie es sich verhält.

In der Praxis habe ich festgestellt, dass BDD in vielen Fällen spröder ist als nur staatliche Tests. Während einige Leute möglicherweise eine bestimmte Theorie fordern, funktioniert sie nur, wenn sie für Sie funktioniert. Staatliche Tests machen immer noch 90% aller von uns geschriebenen Unit-Tests aus, und wir sind uns der BDD in unserem Team bewusst.

Tun Sie, was am besten für Sie funktioniert.

Ein paar Dinge.

Erstens, wenn Sie Dinge wie TDD tun, um Ihren Code testbar zu machen, erhalten Sie eine kleinere Klasse. Wenn Sie eine Klasse mit vielen privaten Eigenschaften haben, die Sie nicht überprüfen können, gibt es eine gute Chance, dass sie in mehrere Klassen unterteilt und nachweisbarer gemacht werden kann.

Zweitens versucht die OO -Architektur Oldschool, Software sicher zu machen, indem sie Sprachsicherung verwenden, um zu verhindern, dass die Dinge zugänglich sind. Eine TDD -Architektur macht die Software durch das Schreiben von Tests, die überprüft, was der Code tatsächlich tut, robuster.

Schließlich ist das Überprüfen einer Eigenschaft nicht der einzige Weg, um den Code zu validieren, was er tun sollte. Das Buch Xunit -Design mustert sich hier dokumentiert hier andere Ansätze: http://xunitpatterns.com/result%20verication%20Patterns.html

Ich rufe die öffentlichen Eingabemethoden eines Systems auf (dh ich drücke Eingabedaten in das System) und erhalte (und behaupte) die Ausgabe des Systems. Ich teste nicht den internen Zustand des Systems, sondern das öffentliche/sichtbare Verhalten: Sollte eine interne Implementierung oder nur das öffentliche Verhalten testen?

Was Sie erwähnen, heißt staatliche Tests. Es gibt auch Verhaltenstests. Die dafür verwendeten Techniken sind Abhängigkeitsinjektion, Kontrollinversion und Verspottung:

Alle Nebenwirkungen Ihrer Klasse werden als Methodenaufrufe zu ihren "Abhängigkeiten" implementiert - dh von außen geliefert, normalerweise im Konstruktor. Dann liefern Sie in Ihrem Einheitstest ein gefälschtes Objekt anstelle eines echten. Das gefälschte Objekt kann sich daran erinnern, ob seine bestimmte Methode aufgerufen wurde, und das ist es, was Sie in Ihrem Test behaupten.

Es gibt eine Anzahl von Spott -Frameworks, die die Erstellung von Scheinobjekten automatisieren, indem Klassen dynamisch generiert werden, die eine bestimmte Schnittstelle implementieren. Am beliebtesten sind Rhino.Mocks und Moq.

Hey Justin, wie du, ich habe kürzlich darüber nachgedacht, mein nur Schreibdomain-Objekt Getter hinzuzufügen, um Unit-Tests zu testen, aber jetzt bin ich überzeugt, dass ich falsch war. Angenommen, Sie haben sich in erster Linie in die Idee einer Domain nur geschrieben, wenn Sie überhaupt Getter haben, fragen Sie nach Ärger. Das Domänenprinzip nur Schreibdomänen möchte, dass Sie ein Ereignis aus Ihrem Domänenobjekt abfeuern oder aus einer Projektion lesen, die Ihr Domain-Objekt geschrieben hat, oder so ähnlich. Sobald Sie Getter entlarvten, beginnen Sie, die "Form" des Objekts aufzudecken, und wie Greg Young sagt: "Domain -Objekte haben Verhalten, keine Form".

Davon abgesehen kämpfe ich mit der gleichen Frage ... wie testet Sie ein Einheit ein nur Schreibdomänenobjekt? Hier ist mein aktueller Plan: Ich denke darüber nach, mein Domain -Objekt zu einem Domain -Ereignis zu machen, in dem "diese Eigenschaften geändert" werden, und in meinem Unit -Test werde ich mich dafür registrieren, bevor ich den "editCommand" sende. Schauen Sie sich Udi Dahans Post zu Domain -Events an hier, und auch sehen Was Eric Evans über Domain -Ereignisse sagt.

Ich habe mich dasselbe gefragt, bis ich endlich auf die folgenden Papiere gestoßen bin. Ich fand sie großartige Primer für die Durchführung von Verhaltensüberprüfung, insbesondere die erste, die mir mehrere "Aha -Momente" zur Verfügung stellte:

  1. Verwenden von Mocks und Tests zur Gestaltung rollenbasierter Objekte
  2. Scheinrollen, keine Objekte
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top