Gibt es zu viele Behauptungen in diesem einen Unit-Test?Gibt es zu viele Behauptungen in diesem Komponententest?
Ich glaube nicht, dass dieser Code eine Erklärung erfordert, aber wenn es so ist, lass es mich wissen.
Ich versuche, meine UnitTests ziemlich klein zu halten und eine Sache nach der anderen zu testen. Also würde ich wahrscheinlich getrennte Teile zu separaten Tests machen, z.
sendWillSendAnEmail,fromContainsSenderAddress,toContainsRecipientAddress,mailBodyContainsMailMessage,mailContainsSubjectAber enden Sie nicht mit viel wiederholtem Code oder viel Infrastruktur-y-Code, um diese verschiedenen Tests einzurichten? Ist es das wirklich wert? – Arlen
@Arlen: Meine Einheit testet Zelt, um ein wenig Code zu wiederholen, aber halten Sie dies auf ein Minimum, indem Sie Factory-Methoden für Test-Setup und benutzerdefinierte Assert-Methoden verwenden. Der Trick besteht darin, die Code-Duplizierung zu minimieren, um die Wartbarkeit sicherzustellen, aber auch die Lesbarkeit sicherzustellen. Das ist die Kunst des Komponententestens :-) – Steven
@Arlen Ich setze normalerweise entweder ein, was in der Setup-Methode benötigt wird, so dass es in jedem Test verfügbar ist oder schreibe einen Helfer, um den Status zu setzen - was auch immer weniger Code ist. Das funktioniert ziemlich gut und mit sehr wenig Code-Duplizierung für mich. Sie haben Ihrer Frage kein Sprachtag hinzugefügt, daher sollte ich beachten, dass ich PHPUnit verwende. PHPUnit ist ein xUnit-Framework, also denke ich, dass das gleiche mit Ihrem Framework möglich sein sollte. – Gordon
Nein im Allgemeinen die mehr Behauptungen, desto besser. Ein häufiger Fehler in Komponententests ist nicht explizit genug.
Ihr Test ist sehr explizit und lesbar. Ich mag besonders die Behauptungen über null. Es ist eine gute Übung, weil es die Interpretation eines Testfehlers extrem einfach macht.
Der einzige Weg, wie Sie zu viele Behauptungen haben können, ist, wenn Sie genau dasselbe mehr als einmal behaupten, was Sie nicht tun.
Ich sehe kein besonderes Problem mit Ihrem behauptet, aber wenn Sie Ihren Code bereinigen möchten, könnten Sie
var session = server.Sessions.FirstOrDefault();
Assert.NotNull(session);
in
var session = server.Sessions.First();
First() eine Ausnahme sowieso ändern werfen, so durch Wenn Sie nur Ihren Code ändern, erhalten Sie den Vorteil, dass die Assert Sie ohne so viel Code bringt. Es gibt andere Orte, an denen Sie ähnliche Änderungen vornehmen können.
Aber als allgemeine Regel, nehmen Sie nichts in Einzeltests vorausgesetzt - und das bedeutet viel behauptet!
Es hängt davon ab, welche Standards du befolgst, aber ich würde im Allgemeinen ja sagen, du hast viel zu viele Behauptungen in diesem Test.
Viele Leute behaupten, dass ein einzelner Test eine einzige Behauptung haben sollte; Ich denke, das kann ein wenig Overkill sein, aber ich glaube natürlich, dass es angemessen ist, einen einzelnen Unit-Test für einen einzelnen "Brocken" an Funktionalität zu haben; Du bist überall mit deinen Behauptungen. Der Test ist zu groß; Zerlegen Sie es in mehrere verschiedene Tests.
Ich denke, die Frage ist, tun die assert() d-Werte unabhängig ändern? Wenn sie sich unabhängig voneinander ändern, sollten sie in verschiedenen Tests getestet werden, die die Bedingungen für jedes Assert variieren.
Wenn Sie jedoch einen einzelnen Codepath haben, der eine E-Mail mit all diesen Feldern generiert, dann ist das Testen all dieser Dinge in einem Test angemessen.
Jetzt ist der Test jedoch etwas schwer zu lesen. Möglicherweise möchten Sie diese Behauptungen in eine beschreibende Hilfsmethode umbrechen. Ich würde mich damit nicht beschäftigen, bis ich finde, dass die gleiche Hilfsmethode woanders nützlich sein könnte.
Ich denke, es ist zu groß.
Wenn Sie eine Reihe kleinerer Tests haben, können Sie eine "Fehlerlokalisierung" erhalten - nur durch Ausführen aller Tests können Sie genau sehen, wo ein Problem liegt. Mit so vielen Behauptungen, wie Sie derzeit haben (und keine Assert-Nachrichten), müssten Sie wahrscheinlich einen Debugger starten, um das herauszufinden. Denken Sie daran, dass Sie wahrscheinlich hunderte, wenn nicht tausende von Tests haben werden, und wenn einige davon versagen, wollen Sie nicht jedes einzelne debuggen, um zu sehen, warum.
Auch jede Assert-Fehler früh im Test bedeutet, dass die späteren Behauptungen nicht ausgeführt werden. Wenn sie in einzelne Tests unterteilt sind, wird jedes Assert überprüft. Das ist eine Art Kompromiss. viele dieser Behauptungen sind wahrscheinlich verwandt und werden gleichzeitig ausfallen, so dass Sie fünf rote Tests anstelle von einem haben werden. Aber ich arbeite von der Prämisse, dass mehr Informationen besser sind, also würde ich lieber diese fünf Tests haben und wissen, dass alle fünf Behauptungen versagt haben.
Ihre vielen Assert-Anweisungen sind ein Indikator dafür, wie viel Logik Sie in Komponententests haben. Sie müssen Ihre Komponententests wie normaler Code pflegen. Es ist besser, die Zeit für defensive Programmierung und Programmierung auf Vertragsbasis zu verwenden, als Unit-Tests zu programmieren.
Vielleicht können Sie eine neue Email-Klasse erstellen, die all diese Parameter in ihrem Standardkonstruktor akzeptiert.
Und dann können Sie eine Ausnahme auslösen, falls der Benutzer einen ungültigen Parameter übergibt.
Und in Ihrem Gerät zu testen
Send_sends_an_email_message
können Sie hinzufügen die behauptet, dass die Kontrollen Gleichheiten nur statt gegen NULL-Werte zu prüfen.
Vielleicht können Sie zwei E-Mails in einem Test erstellen und die Gleichheitserklärungen für beide Instanzen ausführen.
Ja, Sie haben zu viele Behauptungen in Ihrem Code! Darüber hinaus sollte die assert-Anweisung nur eine pro Testmethode sein. Mit vielen Behauptungen kann der Code Geruch sein, dass Sie mehr als eine Sache testen. Darüber hinaus besteht die Möglichkeit, dass jemand neue Beweise in Ihren Test aufnehmen kann, anstatt einen anderen zu schreiben. Und wie kannst du verstehen, wie deine anderen Behauptungen abgeschlossen sind, als die erste fehlschlug?
Sie können auch gefunden interessant, diesen Beitrag: https://timetocode.wordpress.com/2016/06/01/zen-of-unit-testing/
Nur eine Sache zu sagen. Lesen Sie dieses Buch: http://www.amazon.com/Art-Unit-Testing-Examples-Net/dp/1933988274. Sie werden ein anderer Entwickler sein, nachdem Sie es gelesen haben. – Steven
@Steven: Ich werde es lesen; Danke. – Arlen