Was ist zu tun, wenn eine neue Funktion dazu führt, dass vorhandene Komponententests ungültig werden?

Question

Ich baue eine neue Anwendung und versuche, die "Test-First" -Entwicklung so treu wie möglich zu halten. Ich befinde mich in Situationen, in denen ich eine Funktion implementieren/ändern muss, die eine Anzahl bestehender Komponententests ungültig macht. Wie soll ich damit umgehen? Wie ich es sehe, gibt es 3 Möglichkeiten:

• aktualisieren oder entfernen all bestehende Tests die neuen Voraussetzungen für die Funktion (Hinzufügen von mehr als nötig), dann implementieren die Funktion

• Implementieren der gerecht zu werden Feature zuerst, Tests liefen Fehler zu sehen und zu aktualisieren oder bei einem nicht bestandenen Tests entfernen (hinzufügen von mehr als nötig)

• hinzufügen neue Tests für die neue Funktion, die Funktion implementieren, führen Sie alle Tests die alten, um zu sehen es fehlschlagen, entfernen oder Update die alten Tests wie nötig

Die erste Option hält sich an TDD, kann aber quälend kontraproduktiv sein. Die zweite Option ist die einfachste, aber Sie würden nicht zuerst zuverlässig testen und möglicherweise nicht richtig "abgedeckt". Die dritte Option ist ein Kompromiss aus beidem und zu einem gewissen Grad attraktiv, aber Sie laufen Gefahr, einen Test neu zu schreiben, wenn Sie gerade einen alten aktualisiert haben könnten.

Ich habe nicht das Gefühl, dass ich hier eine klare Strategie habe. Was machst du in diesen Situationen?

Answer 1

Ich würde einen Test wählen und ändern, um die neue Funktion zu erfordern. Wenn es keine offensichtlichen Kandidaten gibt, d. H. Es ist wirklich neu, würde ich einen erstellen. Ich würde dann den Code schreiben, um diesen Test zu bestehen. An diesem Punkt würde ich meine anderen Tests durchführen und bemerken, dass einige von ihnen scheitern. An diesem Punkt würde ich jeden Test nacheinander wiederholen und entweder den Test so korrigieren, dass er das neue Feature widerspiegelt (so dass er ohne weitere Codeänderungen bestehen würde) oder den Test im Hinblick auf das neue Feature aktualisieren (was einige weitere Änderungen an dem neuen Feature erfordern könnte) Code im Test).

Answer 2

Ich würde neue Tests für die neue Funktion erstellen und vorhandene Tests aktualisieren, um Ihre Funktion anzupassen. Wenn Sie einen bereits funktionierenden Test unterbrechen, sollten Sie ihn beheben.

Answer 3

Die Implementierung der Funktion beinhaltet Schreiben/Aktualisieren der Komponententests; Das ist grundlegend für die testgetriebene Entwicklung. Ihre zweiten beiden Optionen sind also TDD, nicht nur Ihre erste. In der Praxis vermuten, dass ich Sie Ihre dritte Option mit einigen Mods wollen werden:

1. schreiben Tests für die Funktion (da dies hilft Ihnen, Ihre API/UI für sie validieren)
2. Schreiben Sie den Feature
3. Bewertung die Unit-Tests in diesem allgemeinen Bereich diejenigen zu sehen, dass
4. die Tests
5. Fix diejenigen brechen sollte, die brechen, und wenn es in Ihrer Liste von # 3, die nicht brechen, fixieren (Sie sollten haben gebrochen). Wenn ein Fehler aufgetreten ist, den Sie nicht identifiziert haben, überprüfen Sie, ob dies tatsächlich korrekt ist - beheben Sie den Test oder die Funktion entsprechend.
6. Profit ;-)

Answer 4

Sie sich von den alten Tests befreien und neue schreiben. Vielleicht können Sie Code aus den alten Tests an einigen Stellen ausleihen, aber Sie sind mit Tests philosophisch besser im Einklang mit dem, was Sie versuchen, als zu versuchen, die Art des alten Tests zu ändern.

Tests unterstützen das, was Sie erreichen möchten, und sollten nicht gegen Sie arbeiten.

Answer 5

Ich denke, es gibt zwei Dinge zu beachten. Und ich weiß nicht, ob du nur an eine oder beide denkst.

Der erste Teil besteht darin, dass Sie eine Funktion ändern, da sich die Spezifikation (oder das erwartete Verhalten) ändert. In diesem Fall denke ich, dass es richtig ist, alle Tests zu entfernen, die ein Verhalten beschreiben, das nicht mehr gültig ist. Da ich faul bin, würde ich sie einfach kommentieren oder sie für jetzt überspringen. Dann fange ich an, neue Tests zu schreiben (oder auskommentieren/ändern alte), um zu beginnen, das neue Verhalten zu beschreiben, bis getan.

Der zweite Teil muss tun, wenn Ihre neue Funktion eine Schnittstelle ändert, die von anderen Komponenten verwendet wird, und ihre Tests beginnen, nur weil Sie die Funktion geändert haben. In diesem Fall würde ich die Tests erst nach der Fertigstellung des Features durchführen.

Answer 6

Ich denke, dass alle Ansätze in Ordnung sind. Sie werden zum selben Ergebnis kommen.

Einige Leute mögen kleinere Schritte, und mehr in der ursprünglichen Absicht von TDD arbeiten: Schreiben Sie eine Zeile des Tests, schreiben Sie eine Zeile Code, um es zu beheben, wiederholen. Wenn dies der Fall ist, arbeiten Sie inkrementell zuerst an Ihren alten Tests, entwickeln sie - oder entfernen sie - auf dem neuen System.

Wenn es Ihnen nichts ausmacht, einen größeren Brocken wegzubeißen, tauchen Sie in einen neuen, festen Kram ein. Ich finde, dass dies natürlicher ist, besonders bei der Paarprogrammierung, wenn man etwas mutiger sein kann.

Kann wirklich von Ihrem Komfort und Vertrauensgrad abhängen.

Ich würde die Idee, dass idealerweise eine Änderung sollte nur einen Test brechen, zweitens, so dass Sie möglicherweise möchten, um den Test-Code, so dass dieses Verhalten Sie haben, zu refaktorieren. Eine Art der gemeinsamen Setup-Methode kann die Lösung sein.