Versionskontrolle und testgetriebene Entwicklung

Question

Der Standardprozess für testgetriebene Entwicklung scheint darin zu bestehen, einen Test hinzuzufügen, Fehler zu erkennen, Produktionscode zu schreiben, den Testlauf zu sehen, zu refactorieren und alles in die Quellcodeverwaltung zu überführen.

Gibt es etwas, das Ihnen ermöglicht, die Revision x des Testcodes und die Revision x-1 des Produktionscodes zu überprüfen und festzustellen, dass die Tests, die Sie in Revision x geschrieben haben, fehlschlagen? (Ich würde mich für jede Sprache und Quellcode-Kontrollsystem interessieren, aber ich benutze Ruby und Git)

Es kann Umstände geben, wo Sie Tests hinzufügen könnten, die bereits bestehen, aber sie würden mehr Verifizierung als Entwicklung sein.

Answer 1

Ein paar Dinge:

1. Nach dem Test Refactoring, führen Sie den Test erneut
2. Dann Sie den Code Refactoring, dann führen Sie den Test erneut
3. Dann haben Sie nicht zu überprüfen, sofort in, aber Sie konnte

in TDD, gibt es keinen Zweck, einen Test in der Zugabe, der vergeht. Es ist Zeitverschwendung. Ich war versucht, dies zu tun, um die Codeabdeckung zu erhöhen, aber dieser Code sollte durch Tests abgedeckt werden, die zuerst fehlgeschlagen sind.

Wenn der Test nicht zuerst fehlschlägt, dann wissen Sie nicht, ob der Code, den Sie dann hinzufügen, das Problem behebt, und Sie wissen nicht, ob der Test tatsächlich etwas testet. Es ist nicht mehr ein Test - es ist nur irgendein Code, der Test alles sein kann oder nicht.

Answer 2

Wenn Sie Ihren Produktions- und Testcode in separaten Versionsbereichen aufbewahren (z. B. separate Projekte/Quellbäume/Bibliotheken/etc.), Können Sie mit den meisten Versionskontrollsystemen frühere Codeversionen auschecken und neu erstellen. In Ihrem Fall könnten Sie die x-1-Version des Produktionscodes auschecken, neu erstellen und dann Ihren Testcode für die neu erstellte/bereitgestellte Bereitstellung implementieren.

Eine Sache, die helfen könnte, wäre, Ihren gesamten Code zu markieren/zu etikettieren, wenn Sie eine Veröffentlichung machen, so dass Sie ganz einfach eine gesamte Quellstruktur für eine frühere Version Ihres Codes abrufen können.

Answer 3

Gibt es etwas, das Sie Check-out Revision x des Testcodes ermöglicht, und Revision x-1 der Produktion Code und sehen, dass die Tests, die Sie haben geschrieben in Revision x scheitern?

Ich denke, dass Sie das Schlüsselwort kontinuierliche Integration suchen. Es gibt viele Tools, die tatsächlich als Post-Commit-Hooks in Versionskontrollsystemen implementiert werden (aka etwas, das nach jedem Commit auf Servern/einem zentralen Repository ausgeführt wird): zum Beispiel werden sie nach jedem Commit die Unit-Tests ausführen und die Committer per E-Mail senden Eine Revision führt eine Regression ein.

Solche Werkzeuge sind durchaus in der Lage zu erkennen, welche Tests sind neue und nie von alten Tests bestanden, die passieren verwendet und nicht zur Zeit aufgrund eines kürzlich erfolgten begehen, was bedeutet, dass mit TDD und kontinuierliche Integration ganz einfach ist Gut: Sie werden wahrscheinlich Ihre Tools so konfigurieren können, dass sie nicht schreien, wenn ein neuer fehlgeschlagener Test eingeführt wird, und sich nur über Regressionen beschweren.

Wie immer, ich werde Sie auf Wikipedia für eine generic introduction on the topic verweisen. Und eine detailliertere, ziemlich berühmte Ressource wäre der Artikel aus

Answer 4

Halten Sie einfach Ihre Tests und Code in separaten Verzeichnissen, und dann können Sie eine Version der Tests und eine andere des Codes auschecken.

In einer Multi-Developer-Umgebung möchten Sie in der Regel Code nicht einchecken, wo die Tests fehlschlagen.

Ich würde auch die Motivation dafür in Frage stellen? Wenn es den fehlgeschlagenen Test zuerst "durchsetzen" soll, dann würde ich Sie auf this comment vom Vater des (der Förderung von) TDD verweisen.

Answer 5

"Es kann Umstände geben, in denen Tests hinzugefügt werden können, die bereits bestehen, aber sie sind mehr Verifizierung als Entwicklung."

In TDD Sie immer beobachten Sie einen Test fehlschlagen, bevor es passieren, so dass Sie wissen, dass es funktioniert. Wie Sie festgestellt haben, möchten Sie manchmal Verhalten beschreiben, das durch Code abgedeckt wird, den Sie bereits geschrieben haben, aber wenn Sie von außerhalb der getesteten Klasse betrachtet werden, ist dies ein separates Merkmal der Klasse. In diesem Fall wird der Test bestanden.

Aber immer noch beobachten Sie den Test fehlschlagen.

Schreiben Sie entweder den Test mit einer offensichtlich fehlgeschlagenen Assertion und beheben Sie dann die Assertion, damit sie bestanden wird. Oder brechen Sie den Code vorübergehend ab und beobachten Sie, wie alle betroffenen Tests fehlschlagen, einschließlich der neuen. Und dann beheben Sie den Code, damit es wieder funktioniert.

Answer 6

Wenn Sie git commit nach dem Schreiben Ihrer fehlgeschlagenen Tests und dann erneut, wenn sie übergeben werden, sollten Sie zu einem späteren Zeitpunkt in der Lage sein, eine Verzweigung an dem Punkt zu erstellen, an dem die Tests fehlschlagen.

Sie können dann weitere Tests hinzufügen, überprüfen, dass sie auch fehlschlagen, git commit, git merge und dann die Tests mit der aktuellen Codebasis ausführen, um zu sehen, ob die bereits durchgeführte Arbeit den Test bestanden hat oder jetzt erforderlich ist mach mehr Arbeit.