Sollten fehlgeschlagene Tests dazu führen, dass der kontinuierliche Build fehlschlägt?

Question

Wenn man ein Projekt hat, das Tests beinhaltet, die als Teil des Build-Vorgangs auf einer Build-Maschine ausgeführt werden, sollte der gesamte Build fehlschlagen, wenn ein Satz Tests fehlschlägt?
Was sind die Dinge, die man berücksichtigen sollte, wenn man diese Frage beantwortet? Spielt es eine Rolle, welche Tests fehlschlagen?

---

Hintergrundinformationen, die zu dieser Frage geführt haben:

Derzeit arbeite ich an einem Projekt, das NUnit-Tests beinhaltet, die als Teil des Build-Vorgangs durchgeführt und auf unserer Cruise Control .NET-Build-Maschine ausgeführt werden.

Früher war das Projekt so eingerichtet, dass der Build fehlschlägt, wenn Tests fehlschlagen. Die Begründung dafür war, dass wenn die Tests fehlschlagen, das bedeutet, dass das Produkt nicht funktioniert/nicht komplett ist/es ein Scheitern des Projekts ist, und daher der Build fehlschlagen sollte.

Wir haben einige Tests hinzugefügt, die fehlschlagen, aber nicht entscheidend für das Projekt sind (weitere Details unten). Also, wenn diese Tests fehlschlagen, ist das Projekt kein vollständiges Scheitern, und wir würden immer noch möchten, dass es gebaut wird.

Einer der Tests, der besteht, überprüft, dass falsche Argumente zu einer Ausnahme führen, aber der Test, der nicht besteht, überprüft, dass alle erlaubten Argumente nicht zu einer Ausnahme führen. Die Klasse lehnt also alle ungültigen Fälle ab, aber auch einige gültige. Das ist kein Problem für das Projekt, da die abgelehnten gültigen Argumente Randfälle sind, auf die die Anwendung nicht angewiesen ist.

Answer 1

Wenn es auf irgendeine Weise machbar ist, dann tu es. Es reduziert das Broken-Window-Problem erheblich:

In einem System ohne (sichtbare) Fehler wird das Einführen eines kleinen Fehlers normalerweise als sehr schlechte Idee angesehen. Wenn du also ein Projekt mit einem grünen Status (kein gescheiterter Unit-Test) hast und du den ersten fehlschlagenen Test einführen, dann wirst du (und/oder deine Kollegen) motiviert sein, das Problem zu beheben.

Auf der anderen Seite, wenn bereits bekannte Tests fehlschlagen, wird das Hinzufügen eines weiteren fehlerhaften Tests als das Beibehalten des Status quo angesehen.

Daher solltest du immer darauf achten, alle Tests laufen zu lassen (und nicht nur "die meisten"). Und jede einzelne fehlgeschlagene Test als Grund für das Fehlschlagen des Builds zu behandeln, trägt erheblich dazu bei, dieses Ziel zu erreichen.

Answer 2

Wenn ein Funktionstest fehlschlägt, bedeutet dies, dass bestimmter Code nicht wie erwartet funktioniert. Daher sollte der Code nicht veröffentlicht werden.

Sie können jedoch das Build für Test-/Fehlerbehebungszwecke erstellen.

Answer 3

Wenn Sie das Gefühl hatten, dass ein Fall wichtig genug war, um einen Test dafür zu schreiben, dann, wenn dieser Test fehlschlägt, versagt die Software. Allein aufgrund dieser Tatsache sollte der Build als fehlgeschlagen betrachtet werden und nicht fortgesetzt werden. Wenn Sie diese Argumentation nicht verwenden, wer entscheidet dann, welche Tests nicht wichtig sind? Wo ist die Grenze zwischen "wenn dies fehlschlägt, ist es in Ordnung, aber wenn das fehlschlägt, ist es nicht"? Ein Fehler ist ein Fehler.

Answer 4

Ich denke, dass ein schönes Setup wie Ihres immer erfolgreich erstellt werden sollte, einschließlich aller bestandenen Unit-Tests.

Wie Gamecat sagte, der Build selbst ist erfolgreich, aber dieser Code sollte niemals in die Produktion gelangen.

Stellen Sie sich vor, einer Ihrer Teammitglieder führt einen Fehler im Code ein, den dieser eine Unit-Test (der immer fehlschlägt) abdeckt. Er wird nicht vom Test entdeckt, da Sie es zulassen, dass dieser Test immer fehlschlägt.

In unserem Team haben wir eine einfache Regel: Wenn nicht alle Tests bestehen, gehen wir nicht mit dem Code in die Produktion. Dies ist auch für unseren Projektmanager sehr einfach zu verstehen.

Answer 5

Nach meiner Meinung hängt es wirklich von Ihren Unit-Tests ab,... wenn Ihre Unit-Tests wirklich UNIT-Tests sind (wie sie sein sollten => "Verweis auf endlose Bücher ;)") dann sollte der Build fehlschlagen, weil etwas sich nicht so verhält, wie es sollte...

aber meistens (leider viel zu oft gesehen), in so vielen Projekten decken diese Unit-Tests nur einige 'Kanten' ab und/oder sind Integrationstests, dann sollte der Build weiter ausgeführt werden (ja, dies ist eine subjektive Antwort ;)

kurz gesagt: wenn wissen Sie, dass die Unit-Tests in Ordnung sind: fehlgeschlagen; ansonsten: weiterbauen