Sollte ich weiterhin einen Fehler registrieren?

Question

Ich arbeite an einer automatisierten Regressionstestsuite für eine App, die ich verwalte.Bei der Entwicklung des automatisierten Regressionstests bin ich auf ein Verhalten gestoßen, bei dem es sich mit ziemlicher Sicherheit um einen Fehler handelt.Deshalb habe ich den automatisierten Regressionstest vorerst so geändert, dass er keinen Fehler registriert – ich meine, er lässt dieses schlechte Verhalten absichtlich zu.

Daher bin ich an den Meinungen anderer auf dieser Website interessiert.Natürlich werde ich unserer Fehlerverfolgung einen Fehler hinzufügen, um sicherzustellen, dass dieses Fehlerverhalten behoben wird.Aber gibt es zwingende Gründe (so oder so), den Regressionstest so zu ändern, dass er ständig einen Fehler anzeigt, oder den Regressionstest kaputt zu lassen und keinen Fehler zu haben, bis wir das fehlerhafte Verhalten beheben können?Ich betrachte dies als eine 6 von eineinhalb Dutzend anderen Arten von Fragen, aber ich stelle sie hier, weil ich dachte, dass andere das vielleicht anders sehen.

---

@Paul Tomblin,

Nur um es klarzustellen: Ich habe nie darüber nachgedacht, den Test zu entfernen.Ich habe lediglich darüber nachgedacht, die Pass/Fail-Bedingung zu ändern, um das Scheitern zu berücksichtigen, ohne dass es mir jedes Mal ins Gesicht geschrieben wird, wenn ich den Test durchführe.

Ich mache mir ein wenig Sorgen darüber, dass wiederholte Fehler aus bekannten Gründen in C++ letztendlich wie Warnungen behandelt werden.Ich kenne Entwickler, die Warnungen in ihrem C++-Code sehen und sie einfach ignorieren, weil sie denken, dass es sich nur um nutzlosen Lärm handelt.Ich befürchte, dass das Belassen eines bekannten Fehlers in der Regressionssuite dazu führen könnte, dass die Leute anfangen, andere, möglicherweise wichtigere Fehler zu ignorieren.

Übrigens, damit ich nicht missverstanden werde: Ich halte Warnungen in C++ für eine wichtige Hilfe bei der Erstellung von starkem Code, aber nach den anderen C++-Entwicklern, die ich getroffen habe, zu urteilen, bin ich in der Minderheit.

Answer 1

Ich würde sagen: „Verdammt, ja!“.Die einfache Tatsache ist: Scheitert es?Ja!Dann sollte es protokolliert werden.Sie gefährden Ihre Tests ziemlich, indem Sie zulassen, dass ein fehlgeschlagener Test besteht.

Eine Sache, die mich persönlich beunruhigen würde, ist, dass der „Patch“ möglicherweise nicht entfernt wird, wenn ich dies tun und unter Druck geraten würde, was bedeutet, dass der Fehler möglicherweise auch nach einer „Bugfix“ bestehen bleibt.

Lassen Sie es drin, aktualisieren Sie Ihre Projektnotizen, verringern Sie vielleicht sogar den Schweregrad (wenn möglich), aber machen Sie auf keinen Fall das Ding kaputt, das nach kaputten Dingen sucht ;)

Answer 2

Wenn Sie aufhören, es zu testen, woher wissen Sie dann, wann das Problem behoben ist, und, was noch wichtiger ist, wie erfahren Sie, ob es erneut kaputt geht?Ich bin dagegen, den Test herauszunehmen, weil man dann wahrscheinlich vergisst, ihn wieder einzulegen.

Answer 3

Wir haben unseren Unit-Tests eine Schlummerfunktion hinzugefügt.Dadurch konnte ein Test mit einem Attribut versehen werden, das im Wesentlichen besagte: „Fehler für X Wochen ab diesem Datum ignorieren“.Damit konnten Entwickler einen Test mit Anmerkungen versehen, von dem sie wussten, dass er für eine Weile nicht repariert werden würde, aber es war kein Eingriff in der Zukunft erforderlich, um ihn manuell wieder zu aktivieren, der Test tauchte einfach zum festgelegten Zeitpunkt wieder in der Testsuite auf.

Answer 4

Es sollte ein Fehlschlag bleiben, wenn es nicht das tut, was erwartet wurde.

Ansonsten ist es zu einfach, es zu ignorieren.Halten Sie die Dinge einfach – es funktioniert oder nicht.Misserfolg oder Erfolg :)

– Kevin Fairchild

Answer 5

Während ich mit den meisten Aussagen von Paul übereinstimme, wäre die andere Seite des Arguments, dass Regressionstests streng genommen dazu dienen sollen, Änderungen im Verhalten des Programms zu testen, und nicht irgendeinen alten Fehler.Sie sollen Ihnen ausdrücklich sagen, wenn Sie etwas kaputt gemacht haben, das früher funktioniert hat.

Ich denke, das hängt davon ab, welche anderen Arten von Tests mit dieser App durchgeführt werden.Wenn Sie über eine Art Unit-Test-System verfügen, wäre dies möglicherweise ein geeigneterer Ort für diesen Test als für den Regressionstest (zumindest bis der Fehler behoben ist).Wenn die Regressionstests jedoch Ihre einzigen Tests sind, würde ich den Test wahrscheinlich beibehalten.

Answer 6

Während es am besten ist, Tests fehlschlagen zu lassen, wenn Fehler vorliegen, ist dies oft eine unpraktische Entscheidung.Wenn man einem Bereich zum ersten Mal einen Test hinzufügt, kann es besonders leicht passieren, dass man sich in den entdeckten Fehlern verzettelt und das Hauptziel daher nicht erreicht.Außerdem werden lange fehlgeschlagene Tests immer lauter und können immer leichter ignoriert werden.

Das Schreiben fehlgeschlagener Tests ist Teil der Fehlerbehebung und nur dann wirklich wichtig, wenn die Behebung dieser Fehler wichtig ist.Dies sollte durch Ihre aktuellen Produkt- und Qualitätsprioritäten bestimmt werden.Wenn Sie Tests als Nebeneffekt anderer Bemühungen erstellen, ist das nett, sollte Sie aber nicht von Ihren eigentlichen Prioritäten ablenken.

Ich würde empfehlen, alle bei der Verbesserung der Tests entdeckten Fehler in Warnungen umzuwandeln und entsprechende Fehler zu melden.Es handelt sich um einen auf die Breite ausgerichteten Ansatz, der Sie durch die aktuelle Aufgabe führt und gleichzeitig das Gelernte auch tatsächlich umsetzt.Die Tests können dann leicht in echte Fehler umgewandelt werden, wenn die Fehler behoben werden sollen.

Im Gegensatz zu anderen Befragten bin ich der Meinung, dass Fehler genauso leicht ignoriert werden können wie Warnungen, und dass der Aufwand für die Schulung Ihres Teams zum Ignorieren von Fehlern zu hoch ist, um dies zuzulassen.Wenn Sie im Rahmen dieser Bemühungen fehlgeschlagene Tests produzieren, haben Sie den Nutzen Ihrer Regressionstestsuite zerstört, als die Aufgabe darin bestand, sie zu verbessern.

Answer 7

Ein nicht bestandener Test ist irgendwie ärgerlich.Es gibt einen Unterschied zwischen fehlerhaftem und unvollendetem Code. Ob der Test sofort behandelt werden sollte, hängt davon ab, welche Umstände dieser fehlgeschlagene Test aufdeckt.

Wenn es kaputt ist, sollten Sie es lieber früher als später reparieren.Wenn es noch nicht erledigt ist, kümmern Sie sich darum, wenn Sie Zeit haben.

In beiden Fällen können Sie natürlich damit leben, dass es sich (vorerst) schlecht verhält. Solange das Problem also protokolliert wird, können Sie sich lieber nicht darüber aufregen, bis Sie Zeit haben, es zu beheben.