Zum Beispiel:
%Vor%... oder ...
%Vor%... Ich gehe mit dem späteren und nehme an, dass die Antwort auf meine Frage lautet:
Nein, zumindest nicht mit NUnit, denn gemäß dem NUnit-Handbuch :
Der Konstruktor sollte keine Nebenwirkungen haben, da NUnit die Klasse im Laufe einer Sitzung mehrmals konstruieren kann.
... kann ich auch annehmen, dass es im Allgemeinen eine schlechte Übung ist? Da Tests in der Regel separat ausgeführt werden können. Das Ergebnis von Create darf also niemals mit Delete gelöscht werden.
Ja, es ist eine schlechte Übung. In allen Unit-Test-Frameworks, die ich kenne, ist die Ausführungsreihenfolge der Testmethoden nicht garantiert, daher wird ausdrücklich darauf verzichtet, Tests zu schreiben, die von der Ausführungsreihenfolge abhängig sind.
Wie Sie ebenfalls angemerkt haben, wenn Test B von den (Neben-) Effekten von Test A abhängt, enthält Test A einen allgemeinen Initialisierungscode (der dann stattdessen in eine gemeinsame Setup-Methode verschoben werden sollte), oder die beiden Tests sind Teil von der gleichen Geschichte, so dass sie vereinigt werden konnten (IMHO - einige Leute halten sich an eine einzige Behauptung pro Testmethode, also würden sie mir diesbezüglich widersprechen), oder Test B sollte andernfalls völlig unabhängig von Test A bezüglich des Einrichtungsaufbaus gemacht werden .
Definitiv eine schlechte Idee. Unit-Tests sollten leicht, zustandslos sein und keine Abhängigkeiten von Dingen wie Dateisystem, Registrierung usw. haben. Dies ermöglicht ihnen, schnell zu laufen und weniger brüchig zu sein.
Wenn Ihre Tests in einer bestimmten Reihenfolge ausgeführt werden müssen, können Sie nie sicher sein (zumindest ohne Untersuchung), ob ein Test aufgrund der Ausführungsreihenfolge oder eines Problems mit dem Code fehlgeschlagen ist!
Dies wird letztendlich dazu führen, dass sich das Vertrauen in Ihre Test-Suite und die damit verbundene Aufgabe nicht mehr so schnell entwickelt.
Im Allgemeinen ist es eine gute Übung, dass jeder Ihrer Tests genau eine Sache oder eine Abfolge von Dingen testet. (Sie sind verschiedene Arten von Tests, aber trotzdem.) Außer wenn Sie den Konstruktor oder Destruktor selbst testen, sollten sie als Teil des Test-Setup- und Teardown-Codes und nicht als Tests selbst ausgeführt werden. Es ist in Ordnung, diesbezüglich ineffizient zu sein; Das Wichtigste bei einem Test ist, dass genau klar ist, was getestet wird, und nicht, dass Sie die Anzahl der während des Prozesses durchgeführten Hilfsaktionen minimieren.
Viele Test-Kabelbäume erlauben es Ihnen auch, nur eine Teilmenge von Tests auszuführen (minimal nur eine). Dies ist ideal, wenn Sie sich auf einen bestimmten Fehler konzentrieren! Aber es bedeutet, dass die Tests so geschrieben werden müssen, dass keine Abhängigkeiten bestehen oder alles ziemlich bedeutungslos ist.
Persönlich würde ich das Testen von Konstruktoren und Destruktoren früher in meine Testsuite einfügen als das Testen des Verhaltens der konstruierten Instanzen, aber YMMV.
Tags und Links unit-testing nunit