Fügen Sie für jeden neuen Fehler einen Komponententest hinzu

In meinem Job müssen alle Entwickler, die einen Fehler beheben, einen neuen Komponententest hinzufügen, der vor dieser Art von Fehlern warnt (falls er erneut auftritt). Wenn ein Komponententest nicht möglich ist (z. B. ein Webseitenentwurfsproblem), muss die QA-Abteilung einen Testfall erstellen, um ihn manuell zu überprüfen.

Die Idee dahinter ist, dass, wenn ein Defekt vor der Produktfreigabe nicht erkannt wurde, kein geeigneter Komponententest vorhanden ist, um ihn zu erkennen. Also muss der Entwickler es hinzufügen.

Die Frage ist: Ist dies in jeder Softwareentwicklungsmethodik üblich? Diese Technik hat einen Namen? Ich würde gerne mehr darüber erfahren, benötige aber zunächst einige Informationen.

Das ist durchaus üblich. Wir nutzen dies in unserem Team. Für jeden Produktionsfehler muss der Entwickler einen Hinweis zur Hauptursache des Problems, einen fehlgeschlagenen Komponententest und eine Testauswirkungsanalyse hinzufügen, bevor das Ticket in den Entwicklungsstatus versetzt werden kann, um den Code einzuchecken.

Der fehlerhafte Komponententest muss bestanden werden, bevor wir den Code an die Produktion senden können.

Ich glaube nicht, dass dies einen bestimmten Namen hat, außer dem allgemeinen "Regressionstest". Dies ist sehr nützlich und wir haben begonnen, die Qualität des Produkts zu verbessern, nachdem wir begonnen haben, diesem Prozess zu folgen.

Absolut!

Wenn Sie zustimmen können, dass Komponententests eine gute Sache sind, werden Sie feststellen, dass bei einem Fehler ein Komponententest fehlt, der diesen Codepfad abdeckt.

Was also passieren sollte, ist, dass Sie einen Komponententest schreiben, der anzeigt, dass der Fehler vorliegt, den tatsächlichen Fehler beheben und dann den Komponententest bestehen.

Wenn Sie überhaupt keine Komponententests haben, kann dies eine gute Möglichkeit sein, Komponententests in ein Projekt einzuführen.

Die Technik ist eine testgetriebene Entwicklung. Es geht nicht wirklich darum, beim nächsten Mal einen ähnlichen Fehler zu entdecken, obwohl die Reihe wiederholbarer Tests immer hilfreich ist. Der Punkt ist, dass Sie demonstrieren können, dass Sie das, was mit dem Code falsch ist, isoliert, bewiesen haben, dass es falsch ist, es repariert und bewiesen haben, dass das Update korrekt ist.

Es gibt ein Zitat, an das ich mich nicht erinnern oder das ich nicht finden kann, aber ungefähr ist es: "Jeder Fehler ist ein Test, der noch nicht geschrieben wurde."

Der Versuch, es als Regressionstest zu verkaufen, ist ein verlorener Kampf, IMHO. In Anbetracht dessen, wie selten diese Dinge einen wiederholten Fehler finden, werden die meisten Entwickler nur sagen: "Warum sich die Mühe machen, wenn ich es einfach beheben kann?"

Diese Technik ist weit verbreitet und der beste Name dafür ist meiner Meinung nach "Defect Driven Testing" (ich habe sie mir selbst ausgedacht und sie dann vor langer Zeit unter diesem Namen beschrieben gefunden ).

Es kann vorkommen, dass manche Leute diese Tests als „Regressionstests“ bezeichnen, aber ich persönlich finde es etwas schwierig, diesen Namen zu rechtfertigen. Eine etwas weiter verbreitete Definition (und eine, die für diesen Namen wahrscheinlich viel sinnvoller ist) von "Regressionstests" ist "Ausführen von Tests nach jeder Änderung des Codes, um sicherzustellen, dass Sie keine Regressionen eingeführt haben" und Ihr CI Das Testen jedes Zweigs beim Push an das Repository erfüllt diese Anforderung.