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

Wenn Endbenutzer in der Produktion einen schwerwiegenden Fehler feststellen, erscheint es mir vernünftig, einen fehlgeschlagenen Komponententest hinzuzufügen, um diesen Fehler zu beheben. Auf diese Weise wird der Build absichtlich abgebrochen, bis der Fehler behoben ist. Mein Grund dafür ist, dass der Build die ganze Zeit fehlschlagen sollte , aber nicht aufgrund einer unzureichenden automatisierten Testabdeckung.

Einige meiner Kollegen waren sich nicht einig, dass ein fehlgeschlagener Unit-Test nicht eingecheckt werden sollte. Ich stimme dieser Sichtweise in Bezug auf normale TDD-Praktiken zu, aber ich denke, dass Produktionsfehler anders gehandhabt werden sollten - schließlich, warum sollten Sie dies zulassen wollen 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 andere Teammitglieder stören kann, aber das hängt ganz davon ab, wie Sie Zweige verwenden.

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, der Build wird jedoch nicht unterbrochen.

Natürlich vermerkt man den ignorierten Test in der Bug-Datenbank, also @Ignorewird der entfernt, sobald der Test behoben ist. Dies dient auch als einfache Überprüfung der Fehlerbehebung.

Der Zweck, die Grundlage für fehlgeschlagene Tests zu brechen, besteht nicht darin, das Team unter Druck zu setzen, sondern es auf ein Problem aufmerksam zu machen. Sobald das Problem identifiziert und in der Fehlerdatenbank abgelegt wurde, macht es keinen Sinn, den Test für jeden Build ausführen zu lassen - Sie wissen, dass dies fehlschlagen wird.

Natürlich sollte der Fehler immer noch behoben sein. Die Planung der Fehlerbehebung ist jedoch eine geschäftliche Entscheidung und daher nicht das eigentliche Anliegen des Entwicklers. Sobald ein Fehler in der Fehlerdatenbank abgelegt wurde, ist dies für mich kein Problem mehr, bis der Kunde / Product Owner mir mitteilt, dass er die Fehlerbehebung wünscht .

Warum sollten Sie zulassen, dass ein Build bei 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 ein paar Tage zu verzögern, die für den Komponententest und die Fehlerbehebung erforderlich sind.

Und warum sollte der Build jedes Mal absichtlich abgebrochen werden, wenn ein Fehler auftritt? Wenn Sie es gefunden haben, reparieren 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.

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

"Build abbrechen" bedeutet , dass ein Build nicht erfolgreich abgeschlossen werden kann . Ein nicht bestandener 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 einer Regression (ein Test, der früher bestanden hat und nicht mehr besteht) Regression fand statt.

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

Wie @BenVoigt in seiner 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 fehlerhaften Test ausgeliefert werden.

Was Sie sich in dieser Situation fragen sollten, ist,

Was sollen die Tests leisten?

Wenn die Tests nur dazu dienen, dass sich alle im Hinblick auf den Code wohl fühlen, ist das Hinzufügen eines fehlgeschlagenen Tests, damit sich alle im Hinblick auf den Code schlecht fühlen, nicht produktiv. Aber wie produktiv sind die Tests überhaupt?

Ich behaupte, dass die Tests die geschäftlichen Anforderungen widerspiegeln sollten . Wenn also ein "Fehler" gefunden wurde, der darauf hinweist, dass eine Anforderung nicht ordnungsgemäß erfüllt wurde, ist dies auch ein Hinweis darauf, dass die Tests die Geschäftsanforderungen nicht ordnungsgemäß oder nicht 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 bei der Festlegung des Codes ist vom Unternehmen zu bestimmen. Aber kann diese Priorität wirklich bestimmt werden, bis die Tests festgelegt sind? Das Unternehmen sollte mit dem Wissen ausgestattet sein, was genau scheitert, wie es scheitert und warum es scheitert, um Prioritätsentscheidungen zu treffen. Die Tests sollten dies anzeigen.

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

Um es anders auszudrücken ... Der Build ist bereits kaputt. Sie entscheiden lediglich, ob Sie auf diese Tatsache aufmerksam machen möchten oder nicht.

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

Es ist eine gute Idee, einen Test zu schreiben, von dem Sie wissen, dass er fehlschlägt, bis der Fehler behoben ist. Es ist die Basis von TDD.

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

Beispiel 1
Was passiert, wenn Ihre Anwendung sehr unterschiedlich ist und viele Komponenten enthält? 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 passiert, wenn der erste Fehler schwer zu beheben ist und Sie einen anderen Fehler mit höherer Priorität finden? Brichst du auch den Build für den zweiten Bug? 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 im Rahmen einer Managementdiskussion), um die Vor- und Nachteile der Veröffentlichung eines Builds mit bekannten Fehlern abzuwägen. Dies ist sehr häufig in der Softwareentwicklung der Fall, da praktisch alle wichtigen Softwareprodukte mit zumindest einigen bekannten Problemen veröffentlicht werden.

Dies hängt von der Rolle ab, die die Tests spielen sollen, und davon, wie sich ihre Ergebnisse auf das angewendete Build-System / den angewendeten Build-Prozess auswirken sollen. Ich verstehe das Brechen des Builds genauso wie Ben, und gleichzeitig sollten wir nicht wissentlich Code einchecken, der vorhandene Tests bricht. Wenn diese Tests "später" eingingen, kann es "in Ordnung" sein, sie zu ignorieren, um andere nicht unnötig zu stören, aber ich finde diese Praxis, fehlgeschlagene Tests zu ignorieren (so dass sie zu bestehen scheinen), eher beunruhigend (besonders so) für Komponententests), es sei denn, es gibt eine Möglichkeit, solche Tests als weder rot noch grün anzuzeigen.

Das hängt natürlich vom Fehler ab. Wenn jedoch im Allgemeinen ein Fehler aufgetreten ist, der beim manuellen oder automatischen Testen nicht festgestellt wurde, bedeutet dies, dass Ihre Berichterstattung lückenhaft ist. Ich würde auf jeden Fall dazu ermutigen, die Ursache herauszufinden und einen Unit-Test-Fall auf das Problem zu setzen.

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

Abhängig von Ihrer Veröffentlichungsrichtlinie 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?) korrekte Anforderungen in den neuen Unit-Tests.

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

Sie möchten Ihrem Team nicht dabei helfen, sich auf diese Denkweise einzulassen.

Daher stimme ich sleske zu, dass Sie den Test hinzufügen sollten , ihn jedoch für den Zweck des automatischen Builds als "ignoriert" markieren , bis der Fehler behoben ist.

Obwohl ich denke, dass Sie den Fehler in irgendeiner Weise als Test "einchecken" sollten, damit er nicht erneut auftritt, wenn Sie ihn beheben, und in gewisser Weise Prioritäten setzen, ist es meines Erachtens am besten, den Build (/ die Tests) nicht zu unterbrechen. . Der Grund dafür ist, dass später bahnbrechende Commits hinter Ihrem kaputten Test verborgen bleiben. Wenn Sie also einen fehlerhaften Test für diesen Fehler einchecken, müssen Sie das gesamte Team mit der Behebung dieses Fehlers beauftragen. Wenn dies nicht der Fall ist, brechen Sie möglicherweise Commits, die als solche nicht nachvollziehbar sind.

Daher würde ich sagen, dass es besser ist, diesen Test als ausstehenden Test festzulegen und ihn in Ihrem Team als vorrangig zu betrachten, wenn keine Tests ausstehen.

Eine andere Möglichkeit besteht darin, den fehlgeschlagenen Test in einem separaten Zweig Ihres Versionsverwaltungssystems einzuchecken. Abhängig von Ihren Praktiken kann dies durchführbar sein oder nicht. Manchmal eröffnen wir eine neue Filiale für die laufende Arbeit, zum Beispiel um einen Fehler zu beheben, der nicht trivial ist.