Als eine Fortsetzung der Diskussion in den Kommentaren von diese Antwort , sollte ein TDD-Test immer zuerst fehlschlagen?
Betrachten Sie das folgende Beispiel. Wenn ich eine Implementierung von LinkedHashSet schreibe und einen Test durchführe Nach dem Einfügen eines Duplikats befindet sich das Original in der gleichen Iterationsreihenfolge wie vor dem Einfügen. Möglicherweise möchte ich einen separaten Test hinzufügen, der besagt, dass das Duplikat überhaupt nicht im Satz enthalten ist.
Es wird beobachtet, dass der erste Test zuerst fehlschlägt und dann implementiert wird.
Das Problem ist, dass es sehr wahrscheinlich ist, dass die Implementierung, um den ersten Testdurchlauf durchzuführen, eine andere Set-Implementierung zum Speichern der Daten verwendet hat, so wie ein Nebeneffekt der zweite Test bereits besteht.
Ich würde meinen, dass der Hauptzweck des Tests darin besteht, sicherzustellen, dass der Test ein guter Test ist (oft habe ich einen Test geschrieben, von dem ich dachte, dass er scheitern würde, aber nicht, weil der Test falsch geschrieben wurde). Aber wenn Sie sicher sind, dass der Test, den Sie schreiben, tatsächlich etwas testet, ist es nicht wichtig, dass Sie sicherstellen müssen, dass Sie dieses Verhalten später nicht brechen?
Natürlich ist es wertvoll, denn dann ist es ein nützlicher Regressionstest . Meiner Meinung nach sind Regressionstests wichtiger als das Testen von neu entwickeltem Code.
Zu sagen, dass sie zuerst immer scheitern müssen, ist eine Regel jenseits der Praktikabilität.
Ja, TDD-Tests müssen fehlschlagen, bevor sie grün werden (Arbeit). Ansonsten wissen Sie nicht, ob Sie einen gültigen Test haben.
TDD ist für mich eher ein Design-Tool, kein nachträglicher Einfall. Also gibt es keinen anderen Weg, der Test wird scheitern, einfach weil es keinen Code gibt, der es passieren lässt, erst nachdem ich es erstellt habe, dass der Test jemals bestehen kann.
Ich denke, der Punkt des "Scheiterns zuerst" ist, dass Sie sich nicht selbst veräppeln, dass ein Test funktioniert hat. Wenn Sie eine Reihe von Tests haben, die dieselbe Methode mit verschiedenen Parametern überprüfen, wird eine (oder mehrere) von ihnen wahrscheinlich von Anfang an übergeben. Betrachten Sie dieses Beispiel:
%Vor%Die Tests würden etwa lauten:
%Vor%Einer dieser Tests wird bestanden, aber die anderen nicht. Daher müssen Sie den Code ordnungsgemäß implementieren, damit die Tests bestanden werden. Ich denke, das ist die wahre Anforderung. Der Sinn der Regel besteht darin, sicherzustellen, dass Sie über das erwartete Ergebnis nachgedacht haben, bevor Sie mit dem Hacken beginnen.
Was Sie eigentlich fragen, ist, wie Sie den Test testen können, um zu verifizieren, dass es ein gültiger ist und er testet, was Sie beabsichtigen.
Es zunächst zu scheitern, ist eine gute Option, aber beachten Sie, dass selbst wenn es fehlschlägt, wenn es fehlschlägt und erfolgreich ist, nachdem Sie den Code umgestaltet haben, um Erfolg zu haben. still nicht Das bedeutet, dass Ihr Test tatsächlich getestet hat, was Sie wollten ... Natürlich können Sie auch andere Klassen schreiben, die sich anders verhalten, um Ihren Test zu testen ... Aber das ist tatsächlich ein Test, der Ihren ursprünglichen Test testet - Woher wissen Sie, dass das neuer Test ist gültig? : -)
Es ist also eine gute Idee, einen Test zuerst zu versagen, aber er ist immer noch nicht narrensicher.
IMHO, die Wichtigkeit des Scheiterns zuerst ist, um sicherzustellen, dass der Test, den Sie erstellt haben, keinen Fehler hat. Sie könnten zum Beispiel die Assert in Ihrem Test vergessen, und Sie würden das vielleicht nie wissen.
Ein ähnlicher Fall tritt auf, wenn Sie Grenztests durchführen. Sie haben bereits den Code erstellt, der sie abdeckt, aber es wird empfohlen, dies zu testen.
Ich denke, das ist kein großes Problem für Ihren Test, um nicht zu versagen, aber Sie müssen sicherstellen, dass es tatsächlich testet, was es sollte (Debugging, vielleicht).
Tags und Links language-agnostic tdd