Wenn Sie Code ändern, für den ein Komponententest vorliegt, welchen ändern Sie zuerst?

Wenn Sie TDD praktizieren, sollten Sie zuerst Ihre Tests aktualisieren. Sie haben fehlerhafte Testfälle, die hoffentlich behoben werden, wenn Sie Ihren Code reparieren.

Wenn Sie die erste Entwicklung testen, müssen Sie mindestens einen neuen Test schreiben, der die Änderung rechtfertigt. Die Änderung könnte dann die alten Tests durchbrechen, und Sie könnten sie beheben, nachdem Sie einen Fehler festgestellt haben, wenn die Änderung für den Test unwesentlich ist. Wenn Sie jedoch wissen, dass der Test zum Testen des alten Verhaltens verwendet wurde und nur für das neue Verhalten geändert werden muss, gibt es keinen Grund, diesen Test nicht einfach zu ändern, anstatt einen neuen zu schreiben.

Es lohnt sich nicht (aus meiner Sicht), herauszufinden, welche Tests mit der Änderung brechen und sie alle zuerst ändern, weil der Testläufer Ihnen das sagt, nachdem Sie die Änderung vorgenommen haben.

BEARBEITEN (als Antwort auf einen Kommentar): Ich bevorzuge es, zuerst den Test zu schreiben, aber das ist der TDD-Stil. In diesem Fall wird das Design des Tests vorangetrieben. Es gibt auch einen Rhythmus und Muster für diese Art von Entwicklung (Rot-Grün-Refactor). Andersherum ist mehr der reine Unit-Test-Weg, Sie haben bereits entworfen und implementiert, was Sie wollen, jetzt testen Sie es. Es ist nichts falsch daran, es ist ein anderer Entwicklungsansatz und die Wahl hängt nicht von der Existenz anderer Tests ab. Es ist wirklich ein Entwicklungsansatz im Allgemeinen.

Ich gebe zu, dass ich manchmal betrüge. Wenn eine Änderung einfach genug ist, dass ich das Ergebnis mit Gewissheit wissen kann, werde ich manchmal den Code ändern und dann testen. Wie wenn ich eine Zahl mit einer Konstante multipliziere und alles, was ich tue, die Konstante ändere, werde ich mit der Änderung fortfahren und danach den Testfall aktualisieren.

Wenn Sie etwas tun, das sogar etwas komplexer ist, rate ich Ihnen, sich an die TDD-Orthodoxie zu halten und zuerst den Test zu ändern. Definieren Sie, was Sie tun möchten, bevor Sie es tun. Außerdem würde ich empfehlen, neue Tests nach bereits vorhandenen Tests zu erstellen, sodass Tests zu bereits vorhandenen Funktionen, die Sie beibehalten möchten, zuerst ausgeführt werden, um sicherzustellen, dass Sie nichts kaputt gemacht haben (oder Sie alarmiert haben) so früh wie möglich, dass Sie).

Was ich mache, ist Code zuerst und dann erstellen Tests danach. Da Sie einen Fall haben könnten, in dem Sie Ihren Test so programmieren, dass er auf irgendeine Weise funktioniert, und dann, wenn Sie programmieren, erkennen Sie, dass Sie das nicht tun können. Daher müssen Sie die Tests erneut ändern.

Ich persönlich bevorzuge es, zuerst die Funktionalität zu schreiben und dann die Komponententests durchzuführen (wenn es für die spezifische Funktionalität erforderlich ist). Wenn es etwas ist, das es nicht wirklich wert ist, getestet zu werden, überspringe ich es normalerweise. Ich habe festgestellt, dass es normalerweise Zeitverschwendung ist, Unit-Test zu all code hinzuzufügen, den Sie schreiben. Es gibt sicherlich einen Ort, wo es sehr nützlich ist, aber das erstreckt sich kaum auf all Ihren Code.

Es ist leicht, die vergeudete Produktivität zu erkennen, wenn Sie etwas umgestalten, und erkennen, dass Sie die Hälfte der Komponententests gebrochen haben, die anfangs keinen wirklichen Mehrwert bringen; weil ein Fehler von Anfang an leicht entdeckt worden wäre. All diese Bemühungen sind also Zeitverschwendung. Wenn Sie in einer Umgebung arbeiten, in der es keinen Anreiz gibt, schnell zu liefern und sich schnell anzupassen, dann ist es wahrscheinlich, dass Tonnen von Unit-Tests machbar sind. Sonst haben Sie Ihre Kosten um ein ganzes Bündel erhöht, ohne Ihren Benutzern einen so hohen Mehrwert zu bieten.