it-swarm.com.de

Sollte ich den Build absichtlich abbrechen, wenn in der Produktion ein Fehler gefunden wird?

Es erscheint mir vernünftig, dass, wenn Endbenutzer in der Produktion einen schwerwiegenden Fehler feststellen, ein fehlgeschlagener Komponententest hinzugefügt werden sollte, um diesen Fehler abzudecken, wodurch der Build absichtlich unterbrochen wird, bis der Fehler behoben ist. Mein Grund dafür ist, dass der Build sollte die ganze Zeit fehlgeschlagen sein, aber nicht auf eine unzureichende automatisierte Testabdeckung zurückzuführen ist.

Einige meiner Kollegen waren sich nicht einig, dass ein fehlgeschlagener Komponententest nicht eingecheckt werden sollte. Ich stimme diesem Standpunkt in Bezug auf normale TDD-Praktiken zu, aber ich denke, dass Produktionsfehler anders behandelt werden sollten - schließlich, warum sollten Sie dies zulassen? ein Build, um mit bekannten Fehlern erfolgreich zu sein?

Hat jemand andere bewährte Strategien für den Umgang mit diesem Szenario? Ich verstehe, dass das absichtliche Unterbrechen des Builds für andere Teammitglieder störend sein kann, aber das hängt ganz davon ab, wie Sie Zweige verwenden.

413
MattDavey

Unsere Strategie ist:

Checken Sie einen fehlgeschlagenen Test ein, kommentieren Sie ihn jedoch mit @Ignore("fails because of Bug #1234").

Auf diese Weise ist der Test vorhanden, aber der Build wird nicht unterbrochen.

Natürlich notieren Sie den ignorierten Test in der Bug-Datenbank, also die @Ignore wird entfernt, sobald der Test behoben ist. Dies dient auch als einfache Überprüfung für die Fehlerbehebung.

Der Grund, den Aufbau fehlgeschlagener Tests zu brechen, besteht nicht darin, das Team irgendwie unter Druck zu setzen, sondern es auf ein Problem aufmerksam zu machen. Sobald das Problem erkannt und in der Fehlerdatenbank abgelegt wurde, macht es keinen Sinn, den Test für jeden Build auszuführen - Sie wissen, dass er fehlschlagen wird.

Natürlich sollte der Fehler trotzdem behoben sein. Das Planen des Fixes ist jedoch eine geschäftliche Entscheidung und daher nicht wirklich das Anliegen des Entwicklers ... Sobald ein Fehler in der Bug-DB abgelegt ist, ist dies nicht mehr mein Problem, bis der Kunde/Produktbesitzer mir mitteilt, dass er behoben werden soll .

414
sleske

Warum sollten Sie zulassen, dass ein Build mit bekannten Fehlern erfolgreich ist?

Denn manchmal haben Sie zeitliche Einschränkungen. Oder der Fehler ist so geringfügig, dass es sich nicht wirklich lohnt, den Versand des Produkts um einige Tage zu verzögern, die zum Testen und Beheben des Produkts erforderlich sind.

Was bringt es auch, den Build jedes Mal absichtlich zu unterbrechen, wenn Sie einen Fehler finden? Wenn Sie es gefunden haben, beheben Sie es (oder weisen Sie es der Person zu, die es reparieren wird), ohne Ihr gesamtes Team zu stören. Wenn Sie daran denken möchten, einen Fehler zu beheben, müssen Sie ihn in Ihrem Fehlerverfolgungssystem als sehr wichtig markieren.

107

Tests sollen sicherstellen, dass Sie keine Probleme (erneut) einführen. Die Liste der fehlgeschlagenen Tests ist kein Ersatz für ein Fehlerverfolgungssystem. In der POV gibt es eine gewisse Gültigkeit, dass fehlgeschlagene Tests nicht nur auf Fehler hinweisen, sondern auch auf Fehler im Entwicklungsprozess (von Unachtsamkeit bis zu schlecht identifizierter Abhängigkeit).

55
AProgrammer

"Build brechen" bedeutet m zu verhindern, dass ein Build erfolgreich abgeschlossen wird. Ein fehlgeschlagener Test macht das nicht. Dies ist ein Hinweis darauf, dass der Build bekannte Fehler aufweist, was genau richtig ist.

Die meisten Build-Server verfolgen den Status von Tests im Laufe der Zeit und weisen einem Test, der seit dem Hinzufügen fehlgeschlagen ist, eine andere Klassifizierung zu als eine Regression (Test, der früher bestanden wurde und nicht mehr besteht) und erkennen auch die Revision, in der der Test durchgeführt wurde Regression fand statt.

23
Ben Voigt

Ich würde argumentieren, dass der fehlgeschlagene Test hinzugefügt werden sollte, aber nicht explizit als "fehlgeschlagener Test".

Wie @BenVoigt in seine Antwort hervorhebt, muss ein fehlgeschlagener Test nicht unbedingt "den Build brechen". Ich denke, die Terminologie kann von Team zu Team variieren, aber der Code wird immer noch kompiliert und das Produkt kann immer noch mit einem fehlgeschlagenen Test ausgeliefert werden.

Was Sie sich in dieser Situation fragen sollten, ist:

Was sollen die Tests bewirken?

Wenn die Tests nur dazu dienen, dass sich alle gut mit dem Code fühlen, erscheint es nicht produktiv, einen fehlgeschlagenen Test hinzuzufügen, damit sich alle schlecht mit dem Code fühlen. Aber wie produktiv sind die Tests überhaupt?

Meine Behauptung ist, dass die Tests die Geschäftsanforderungen widerspiegeln sollten . Wenn also ein "Fehler" gefunden wurde, der anzeigt, dass eine Anforderung nicht ordnungsgemäß erfüllt wurde, ist dies auch ein Hinweis darauf, dass die Tests die Geschäftsanforderungen nicht ordnungsgemäß oder vollständig widerspiegeln.

Das ist der Fehler, der zuerst behoben werden muss. Sie fügen keinen "fehlgeschlagenen Test hinzu". Sie korrigieren die Tests, um die Geschäftsanforderungen genauer widerzuspiegeln. Wenn der Code diese Tests dann nicht besteht, ist das eine gute Sache. Es bedeutet, dass die Tests ihren Job machen.

Die Priorität des Fixierens des Codes wird vom Unternehmen festgelegt. Aber kann diese Priorität wirklich bestimmt werden, bis die Tests festgelegt sind? Das Unternehmen sollte mit dem Wissen ausgestattet sein, was genau fehlschlägt, wie es fehlschlägt und warum es fehlschlägt, um seine Prioritätsentscheidungen treffen zu können. Die Tests sollten dies anzeigen.

Tests zu haben, die nicht vollständig bestehen, ist keine schlechte Sache. Es wird ein großes Artefakt bekannter Probleme erstellt, das priorisiert und entsprechend behandelt werden muss. Tests zu haben, die nicht vollständig testen , ist jedoch ein Problem. Es stellt den Wert der Tests selbst in Frage.

Anders gesagt ... Der Build ist bereits kaputt. Sie entscheiden lediglich, ob Sie auf diese Tatsache aufmerksam machen möchten oder nicht.

16
David

In unserem Testautomatisierungsteam prüfen wir fehlgeschlagene Tests, solange sie aufgrund eines Produktfehlers und nicht aufgrund eines Testfehlers fehlschlagen. Auf diese Weise haben wir für das Entwicklerteam den Beweis, dass sie es gebrochen haben. Das Brechen des Builds ist hoch verpönt, aber das ist nicht dasselbe wie das Einchecken perfekt kompilierbarer, aber fehlgeschlagener Tests.

13
Yamikuronue

Das Schreiben eines Tests, von dem Sie wissen, dass er fehlschlägt, bis der Fehler behoben ist, ist eine gute Idee. Er ist die Grundlage für TDD.

Den Build zu brechen ist eine schlechte Idee. Warum? Weil es bedeutet, dass nichts weitergehen kann, bis es repariert ist. Es blockiert im Wesentlichen alle anderen Aspekte der Entwicklung.

Beispiel 1
Was ist, wenn Ihre Anwendung mit vielen Komponenten sehr unterschiedlich ist? Was ist, wenn diese Komponenten von anderen Teams mit einem eigenen Release-Zyklus bearbeitet werden? Zäh! Sie müssen auf Ihre Fehlerbehebung warten!

Beispiel 2
Was ist, wenn der erste Fehler schwer zu beheben ist und Sie einen anderen Fehler mit einer höheren Priorität finden? Brechen Sie auch den Build für den zweiten Fehler? Jetzt können Sie erst bauen, wenn beide behoben sind. Sie haben eine künstliche Abhängigkeit erstellt.

Es gibt keinen logischen Grund, warum ein fehlgeschlagener Test einen Build stoppen sollte. Dies ist eine Entscheidung, die das Entwicklerteam treffen muss (möglicherweise mit Managementdiskussion), um die Vor- und Nachteile der Veröffentlichung eines Builds mit bekannten Fehlern abzuwägen. Dies ist in der Softwareentwicklung sehr häufig, so ziemlich alle wichtigen Softwareprodukte werden mit mindestens einigen bekannten Problemen veröffentlicht.

7
Qwerky

Das hängt natürlich vom Fehler ab, aber wenn im Allgemeinen ein Fehler aufgetreten ist, der beim manuellen oder automatisierten Testen nicht festgestellt wurde, bedeutet dies, dass eine Lücke in Ihrer Abdeckung besteht. Ich würde definitiv dazu ermutigen, die Grundursache herauszufinden und einen Unit-Test-Fall auf das Problem zu legen.

Wenn es sich um ein Produktionsproblem handelt, das für einen Hotfix aus einem Wartungszweig geplant ist, müssen Sie auch sicherstellen, dass der Fix auf der Hauptlinie funktioniert und dass ein Entwickler den Fix nicht fälschlicherweise mit einer übereifrigen Lösung von Zusammenführungskonflikten wegblasen kann .

Abhängig von Ihrer Freigaberichtlinie kann das Vorhandensein neu aktualisierter Komponententests außerdem dazu beitragen, zu bestätigen, dass ein Entwickler das Problem tatsächlich behoben hat, anstatt es lediglich zu ändern [(das Problem oder die Tests?)], Obwohl dies davon abhängt, ob das codiert wurde korrekte Anforderungen in den neuen Unit-Tests.

5
Keith Brings

Dies hängt von der Rolle ab, die die Tests spielen sollen, und davon, wie sich ihre Ergebnisse auf das verwendete Build-System/den verwendeten Build-Prozess auswirken sollen. Mein Verständnis, den Build zu brechen, ist das gleiche wie das von Ben, und gleichzeitig sollten wir nicht wissentlich Code einchecken, der bestehende Tests bricht. Wenn diese Tests "später" eingehen, ist es möglicherweise "in Ordnung", sie zu ignorieren, um sie für andere weniger unnötig zu stören, aber ich finde diese Praxis, fehlgeschlagene Tests zu ignorieren (damit sie zu bestehen scheinen), eher störend (insbesondere) für Unit-Tests), es sei denn, es gibt eine Möglichkeit, Tests als weder rot noch grün anzuzeigen.

5
prusswan

Ein Problem beim Hinzufügen eines Know-to-Fail-Tests zum Build besteht darin, dass Ihr Team möglicherweise die Gewohnheit hat, fehlgeschlagene Tests zu ignorieren, da es erwartet, dass der Build fehlschlägt. Es hängt von Ihrem Build-System ab, aber wenn ein fehlgeschlagener Test nicht immer bedeutet, dass "gerade etwas kaputt gegangen ist", ist es einfach, fehlgeschlagenen Tests weniger Aufmerksamkeit zu schenken.

Sie möchten Ihrem Team nicht dabei helfen, in diese Denkweise einzusteigen.

Daher stimme ich sleske zu, dass Sie den Test hinzufügen, aber als 'ignoriert' markieren zum Zweck des automatischen Builds markieren sollten, bis der Fehler behoben ist.

5
Wilka

Ich denke, Sie sollten den Fehler in gewisser Weise als Test einchecken, damit er nicht erneut auftritt, wenn Sie ihn beheben, und ihn in gewisser Weise priorisieren. Ich denke, es ist am besten, den Build (/ die Tests) nicht zu unterbrechen. . Der Grund dafür ist, dass nachträgliche Build-Breaking-Commits hinter Ihrem fehlerhaften Test verborgen werden. Wenn Sie also einen fehlerhaften Test für diesen Fehler einchecken, fordern Sie, dass das gesamte Team seine Arbeit beiseite legt, um diesen Fehler zu beheben. Wenn dies nicht der Fall ist, werden möglicherweise Commits unterbrochen, die als solche nicht nachvollziehbar sind.

Daher würde ich sagen, dass es besser ist, es als ausstehenden Test festzulegen und es zu einer Priorität in Ihrem Team zu machen, keine ausstehenden Tests durchzuführen.

4
markijbema

Eine andere Möglichkeit besteht darin, den fehlgeschlagenen Test in einem separaten Zweig Ihres Quellcodeverwaltungssystems zu überprüfen. Abhängig von Ihren Praktiken kann dies machbar sein oder nicht. Manchmal eröffnen wir eine neue Niederlassung für laufende Arbeiten, z. B. zur Behebung eines nicht trivialen Fehlers.

4
Ola Eldøy