Wenn ein Projekt mit Tests ausgeführt wird, die als Teil der Build-Prozedur auf einer Build-Maschine ausgeführt werden, schlägt ein fehlgeschlagener Set-Test fehl, wenn der gesamte Build fehlschlägt Was sollten Sie bei der Beantwortung dieser Frage beachten? Ist es wichtig, welche Tests fehlschlagen?
Hintergrundinformationen, die diese Frage ausgelöst haben:
Momentan arbeite ich an einem Projekt mit NUnit Tests, die als Teil des Build-Verfahrens durchgeführt werden und auf unserem < ein href="http://ccnet.thoughtworks.com/"> Tempomat .net bauen Maschine.
Früher wurde das Projekt so eingerichtet, dass bei fehlgeschlagenen Tests der Build fehlschlägt. Die Begründung ist, wenn die Tests fehlschlagen, das heißt, das Produkt funktioniert nicht / nicht vollständig / es ist ein Fehler eines Projekts, und daher sollte der Build fehlschlagen.
Wir haben einige Tests hinzugefügt, die, obwohl sie scheitern, für das Projekt nicht entscheidend sind (weitere Einzelheiten finden Sie weiter unten). Wenn diese Tests fehlschlagen, ist das Projekt kein vollständiger Fehler, und wir möchten trotzdem, dass es funktioniert.
Einer der bestandenen Tests stellt sicher, dass inkorrekte Argumente zu einer Ausnahme führen. Der Test besteht jedoch nicht darin, dass geprüft wird, ob alle zulässigen Argumente nicht zu einer Ausnahme führen. Die Klasse weist also alle ungültigen, aber auch einige ungültige Fälle zurück. Dies ist kein Problem für das Projekt, da die zurückgewiesenen gültigen Argumente Randfälle sind, auf die sich die Anwendung nicht verlassen wird.
Wenn es irgendwie machbar ist, dann tu es. Es reduziert das zerbrochene-Fenster-Problem :
In einem System ohne (sichtbare) Fehler wird die Einführung eines kleinen Fehlers normalerweise als eine sehr schlechte Idee angesehen. Wenn Sie also ein Projekt mit einem grünen Status haben (kein Komponententest schlägt fehl) und Sie den ersten fehlgeschlagenen Test einführen, werden Sie (und / oder Ihre Kollegen) motiviert sein, das Problem zu beheben.
Wenn auf der anderen Seite Tests bekannt sind, bei denen Tests fehlschlagen, wird das Hinzufügen eines weiteren abgebrochenen Tests als Status quo angesehen.
Deshalb sollten Sie immer danach streben, alle Tests laufen zu lassen (und nicht nur "die meisten"). Und jeden einzelnen versagenden Test als Grund für das Scheitern des Baus zu behandeln, geht einen langen Weg zu diesem Ziel.
Wenn ein Komponententest fehlschlägt, verhält sich ein Code nicht wie erwartet. Also sollte der Code nicht veröffentlicht werden.
Obwohl Sie den Build zum Testen / Bugfixing machen können.
Wenn Sie der Meinung waren, dass ein Fall wichtig genug ist, um einen Test zu schreiben, schlägt die Software fehl, wenn dieser Test fehlschlägt. Darauf aufbauend sollte ja der Build ein Fehler sein und nicht weitergehen. Wenn Sie diese Argumentation nicht verwenden, wer entscheidet dann, welche Tests nicht wichtig sind? Wo ist die Grenze zwischen "wenn das schief geht, ist es in Ordnung, aber wenn das scheitert, ist es nicht"? Fehler ist ein Fehler.
Ich denke, dass ein nettes Setup wie das Ihre immer erfolgreich erstellt werden sollte, einschließlich aller Unit-Tests, die bestanden wurden.
Wie Gamecat sagte, ist der Build selbst erfolgreich, aber dieser Code sollte niemals in Produktion gehen.
Stellen Sie sich vor, eines Ihrer Teammitglieder könnte einen Fehler im Code einführen, den dieser eine Unit-Test (der immer fehlschlägt) abdeckt. Es wird vom Test nicht erkannt, da Sie zulassen, dass ein Test immer fehlschlägt.
In unserem Team haben wir eine einfache Richtlinie: Wenn alle Tests nicht bestanden werden, gehen wir nicht mit dem Code in die Produktion. Dies ist auch für unseren Projektmanager sehr einfach zu verstehen.
Meiner Meinung nach kommt es wirklich auf Ihre Unit Tests an, ... wenn deine Unit-Tests wirklich UNIT-Tests sind (wie sie sein sollten = & gt; "Bezug auf endlose Bücher;)") dann sollte der Build fehlschlagen, weil sich etwas nicht so verhält, wie es sollte ...
aber meistens (leider zu oft gesehen), in so vielen Projekten decken diese Unit Tests nur einige 'Kanten' ab und / oder sind Integrationstests, dann sollte der Build weitergehen (Ja, das ist eine subjektive Antwort;)
kurz: Weißt du, dass die Unit-Tests in Ordnung sind? sonst: aufbau auf
Das eigentliche Problem liegt bei Ihren fehlgeschlagenen Tests. Sie sollten keinen Komponententest haben, bei dem ein Fehler auftreten kann, da es sich um einen Randfall handelt. Entscheiden Sie, ob der Randfall wichtig ist oder nicht - wenn nicht, dann löschen Sie den Komponententest; Wenn ja, dann fixiere den Code.
Wie bei einigen anderen Antworten auch, ist es definitiv ein Code-Geruch, wenn Komponententests fehlschlagen. Wenn Sie mit dem Geruch leben, dann ist es weniger wahrscheinlich, dass Sie das nächste Problem erkennen.
Alle Antworten waren großartig, hier habe ich mich entschieden:
Machen Sie die Tests (oder wenn nötig, teilen Sie einen fehlgeschlagenen Test), die nicht entscheidend sind, von NUnit ignoriert werden (ich erinnerte mich an diese Funktion, nachdem ich die Frage gestellt hatte). Dies ermöglicht:
Ich denke, das ist der beste Kompromiss, der die Leute zwingt, die Tests zu korrigieren, aber nicht unbedingt sofort (aber sie müssen ihre Entscheidung verteidigen, es jetzt nicht zu reparieren, da jeder weiß, was sie getan haben).
Was ich tatsächlich getan habe: repariere die kaputten Tests.
Tags und Links unit-testing testing continuous-integration