Ich habe eine parametrisierte Testklasse mit einer Reihe von Komponententests, die generell die Erstellung von benutzerdefinierten E-Mail-Nachrichten steuern. Gerade jetzt hat die Klasse viele Tests, die von Faktoren abhängen, die in der parametrisierten Klasse verwendet werden, der Ablauf der Tests ist für jeden Test gleich. Das Beispiel eines Tests:
%Vor%Ich musste meiner E-Mail-Klasse zusätzliche Funktionalität hinzufügen, die einige zusätzliche interne E-Mails zur Liste der Empfänger hinzufügt, und das passiert nur für einige Fälle und das führt zu meinem Problem.
Sagen wir, ich möchte die Menge der erzeugten Nachrichten bestätigen. Für den alten Test war es für jeden Fall dasselbe, aber jetzt ist es je nach Fall unterschiedlich. Der intuitivste Weg für mich war das Hinzufügen von if-Anweisungen:
%Vor%aber mein erfahrener Kollege sagt, wir sollten Wenns in Testklassen vermeiden (und ich stimme dem irgendwie zu).
Ich dachte, der Splitting-Test an zwei Testklassen könnte funktionieren, aber das würde zu redundantem Code in beiden Klassen führen (ich muss immer noch prüfen, ob nicht-iternale Nachrichten erstellt wurden, deren Größe, Inhalt usw.) und ein paar Zeilen für eine von ihnen hinzugefügt.
Meine Frage ist: Wie mache ich das, also verwende ich nicht, wenn es viel redundanten Code gibt (ohne die Verwendung einer parametrisierten Klasse würde noch mehr redundanter Code erzeugt werden)?
Meiner Meinung nach sollte ein Junit wie ein Protokoll gelesen werden. Das bedeutet, dass Sie redundanten Code schreiben können, um den Testfall besser lesbar zu machen. Schreiben Sie einen Testfall für jede mögliche if-Anweisung in Ihrer Geschäftslogik sowie die negativen Fälle. Nur so erhält man eine 100% ige Testabdeckung. Ich benutze die Struktur:
%Vor%Außerdem sollten Sie komplexe Aussagen großer Objekte in eigenen abstrakten Klassen schreiben:
%Vor%Es reduziert die Komplexität Ihres Codes und Sie stellen es anderen Entwicklern zur Verfügung.
Ein Komponententest sollte meiner Meinung nach nur eine Sache testen, wenn es möglich ist. Als solches würde ich sagen, dass Sie, wenn Sie eine if-Anweisung benötigen, wahrscheinlich mehr als einen Komponententest benötigen - einen für jeden Block im if / else-Code.
Wenn möglich, würde ich sagen, dass ein Test wie eine Geschichte lesen sollte - mein bevorzugtes Layout (und das ist nicht meine Idee :-) - es ist ziemlich weit verbreitet) ist:
%Vor%Ein weiterer Vorteil eines Komponententests, der nur eine Sache testet, ist, dass wenn ein Fehler auftritt, dessen Ursache eindeutig ist - wenn Sie einen langen Test mit vielen möglichen Ergebnissen haben, wird es viel schwieriger zu begründen, warum ein Test fehlgeschlagen ist. p>
Warum haben Sie nicht eine private Methode, die die für jede Methode üblichen Dinge testet? So ähnlich (aber wahrscheinlich mit einem Eingabeparameter für die Methode testCommonStuff() ):
Auf diese Weise erhalten Sie keinen redundanten Code und Sie können Ihren Test in kleinere Tests aufteilen. Außerdem machen Sie Ihre Tests weniger fehleranfällig, wenn sie die gleichen Dinge testen sollten. Sie werden immer noch wissen, welcher Test fehlgeschlagen ist, daher sollte die Rückverfolgbarkeit kein Problem darstellen.
Ich bin mir nicht sicher, ob es möglich ist, in einem parametrisierten Test sauber zu machen, was Sie wollen. Wenn Sie ein anderes Testfallverhalten benötigen, das auf dem Parameter für einige Funktionen basiert, können Sie diese Features möglicherweise besser separat testen - in verschiedenen Testklassen, die nicht parametrisiert sind.
Wenn Sie wirklich alles in den parametrisierten Testklassen behalten wollen, wäre ich geneigt, eine Hilfsfunktion zu erstellen, damit Ihr Beispieltest zumindest als einfache Behauptung liest:
%Vor%Tags und Links java unit-testing