___ qstnhdr ___ TDD - Wann kann ein nicht fehlgeschlagener Test geschrieben werden?
___ answer360926 ___
Es gibt zwei Gründe, fehlgeschlagene Tests zuerst zu schreiben und dann auszuführen:
Als Erstes prüfen Sie, ob der Test tatsächlich testet, wofür Sie ihn schreiben. Sie überprüfen zuerst, ob es fehlschlägt, Sie ändern den Code, um den Test auszuführen, und Sie überprüfen, ob er ausgeführt wird. Es scheint dumm, aber ich hatte mehrere Male, wo ich einen Test für Code, der bereits ausgeführt wurde, um später herauszufinden, dass ich einen Fehler in dem Test gemacht hatte, dass es immer ausgeführt hat.
Der zweite und wichtigste Grund ist, dass Sie nicht zu viele Tests schreiben. Tests spiegeln Ihr Design wider und Ihr Design spiegelt Ihre Anforderungen und Anforderungen wider. Sie müssen nicht viele Tests neu schreiben, wenn dies passiert. Eine gute Faustregel ist, dass jeder Test nur aus einem Grund fehlschlägt und nur ein Test aus diesem Grund fehlschlägt. TDD versucht dies zu erzwingen, indem es den Standard-Rot-Grün-Refactor-Zyklus für jeden Test, jede Funktion und jede Änderung in Ihrer Code-Basis wiederholt.
Aber natürlich werden Regeln gebrochen. Wenn Sie bedenken, warum diese Regeln in erster Linie gemacht werden, können Sie flexibel mit ihnen sein. Wenn Sie zum Beispiel feststellen, dass Sie Tests haben, die mehr als eine Sache testen, können Sie sie aufteilen. Effektiv haben Sie zwei neue Tests geschrieben, die Sie noch nie zuvor gesehen haben. Brechen und dann reparieren Sie Ihren Code, um zu sehen, dass Ihre neuen Tests fehlschlagen, ist eine gute Möglichkeit, Dinge zu überprüfen.
___ qstntxt ___
Soweit ich weiß, müssen Sie in TDD zuerst einen fehlgeschlagenen Test schreiben, dann den Code schreiben, um ihn passieren zu lassen, und dann umgestalten. Was aber, wenn Ihr Code bereits die Situation berücksichtigt, die Sie testen möchten?
Nehmen wir zum Beispiel an, dass ich einen Sortieralgorithmus TDD bin (das ist nur hypothetisch). Ich könnte Unit Tests für ein paar Fälle schreiben:
input = 1, 2, 3
Ausgabe = 1, 2, 3
Eingang = 4, 1, 3, 2
Ausgabe = 1, 2, 3, 4
etc...
Um die Tests zu bestehen, komme ich mit einer schnellen, schmutzigen Blasensorte an. Dann refaktoriere ich und ersetze es durch den effizienteren Merge-Sort-Algorithmus. Später merke ich, dass wir eine stabile Sorte brauchen, also schreibe ich auch dafür einen Test. Natürlich wird der Test niemals fehlschlagen, da Merge-Sort ein stabiler Sortieralgorithmus ist! Trotzdem, ich brauche diesen Test immer noch, wenn jemand ihn erneut umstellt, um einen anderen, möglicherweise instabilen Sortieralgorithmus zu verwenden.
Wird damit das TDD-Mantra gebrochen, immer fehlerhafte Tests zu schreiben? Ich bezweifle, dass irgendjemand empfehlen würde, dass ich die Zeit verschwende, einen instabilen Sortieralgorithmus zu implementieren, nur um den Testfall zu testen, und dann die Verschmelzung neu zu implementieren. Wie oft stößt du auf eine ähnliche Situation und was machst du?
___ answer360875 ___
Der große Vorteil, dass der Test zuerst fehlschlägt, ist, dass er sicherstellt, dass Ihr Test wirklich testet, was Sie denken. Sie können subtile Fehler in Ihrem Test haben, die dazu führen, dass er überhaupt nichts wirklich prüft.
Zum Beispiel habe ich einmal in unserer C ++ Codebasis jemanden im Test überprüft:
%Vor%
Offensichtlich haben sie nicht programmiert, so dass der Test zuerst fehlschlug, da dies überhaupt nichts testet.
___ answer367958 ___
Einfache TDD-Regel: Sie schreiben Tests, die könnten fehlschlagen.
Wenn uns die Softwareentwicklung etwas gesagt hat, können Sie die Testergebnisse nicht vorhersagen. Nicht einmal versagt. Es ist tatsächlich ziemlich üblich für mich, "neue Feature-Anfragen" zu sehen, die bereits in vorhandener Software funktionieren. Dies ist üblich, weil viele neue Funktionen einfache Erweiterungen bestehender Geschäftswünsche sind. Der zugrunde liegende, orthogonale Softwareentwurf wird weiterhin funktionieren.
i.e. Neue Funktion "Liste X muss bis zu 10 Elemente enthalten" statt "bis zu 5 Elemente" erfordert einen neuen Testfall. Der Test wird bestanden, wenn die tatsächliche Implementierung von Liste X 2 ^ 32 Elemente zulässt, aber Sie wissen das nicht sicher, bis Sie den neuen Test ausführen.
___ answer369555 ___
Ich bezweifle, dass jemand empfehlen würde, ich verschwende
die Zeit, um ein instabiles zu implementieren
Sortieralgorithmus nur zum Testen der
Testfall, dann reimplementieren Sie die
Zusammenführen, sortieren. Wie oft kommst du?
über eine ähnliche Situation und was tun
tun Sie?
Lass mich derjenige sein, der es dann empfiehlt. :)
Bei all diesen Dingen handelt es sich um Kompromisse zwischen der Zeit, die Sie auf der einen Seite verbringen, und den Risiken, die Sie reduzieren oder mindern, sowie dem Verständnis, das Sie gewinnen.
Fortsetzung des hypothetischen Beispiels ...
Wenn "Stabilität" eine wichtige Eigenschaft / Eigenschaft ist und Sie den Test nicht "testen", indem Sie ihn ausfallen lassen, sparen Sie die Zeit für diese Arbeit, aber Sie riskieren, dass der Test falsch ist und immer sein wird grün.
Wenn Sie andererseits den Test "testen", indem Sie die Funktion unterbrechen und beobachten, dass sie fehlschlägt, reduzieren Sie das Risiko des Tests.
Und die Wildcard ist, Sie könnten ein wenig Wissen gewinnen. Wenn Sie zum Beispiel versuchen, eine "schlechte" Sortierung zu codieren und den Test fehlschlagen zu lassen, denken Sie vielleicht genauer über die Vergleichsbedingungen für den zu sortierenden Typ nach und stellen fest, dass Sie "x == y" als Äquivalenzklassen-Prädikat zum Sortieren, aber tatsächlich ist "! (x & lt; y) & amp; & amp;! (y & lt; x)" das bessere Prädikat für Ihr System (z. B. könnten Sie einen Fehler oder einen Designfehler entdecken).
>
Also ich sage irren auf der Seite von "verbringen Sie die zusätzliche Zeit, um es zum Scheitern zu bringen, auch wenn das bedeutet absichtlich das System zu brechen, nur um einen roten Punkt auf dem Bildschirm für einen Moment zu bekommen", weil während jeder dieser kleinen " Englisch: www.mjfriendship.de/en/index.php?op...39&Itemid=32 Eine Ablenkung "kostet etwas Zeit, hin und wieder wird man ein riesiges Bündel sparen (zB oops, ein Fehler im Test bedeutet, dass ich nie die wichtigste Eigenschaft meines Systems getestet habe, oder Deutsch: oops, unser ganzes Design für Ungleichheitsprädikate ist durcheinander). Es ist wie im Lotto zu spielen, außer die Chancen stehen auf lange Sicht in Ihrem Interesse; jede Woche verbringst du $ 5 für Tickets und normalerweise verlierst du, aber einmal alle drei Monate gewinnst du einen $ 1000 Jackpot.
___ answer360883 ___
Wenn Sie ein neues Stück Code schreiben, schreiben Sie den Test, dann den Code. Dies bedeutet, dass Sie beim ersten Mal immer einen fehlgeschlagenen Test haben (weil er gegen eine Dummy-Schnittstelle ausgeführt wurde). .
Dann können Sie mehrere Male umgestalten, und in diesem Fall müssen Sie möglicherweise keine zusätzlichen Tests schreiben, da der eine bereits ausreicht.
Vielleicht möchten Sie jedoch etwas Code mit TDD-Methoden pflegen; In diesem Fall müssen Sie zuerst Tests als Charakterisierungstests schreiben (die per Definition zu einem nie führen, weil sie gegen Arbeitsschnittstellen ausgeführt werden) und dann refactor.
___ answer360881 ___
Hard Core TDDers würden sagen, dass Sie immer einen fehlgeschlagenen Test benötigen, um zu verifizieren, dass ein positiver Test kein falsch positives Ergebnis ist, aber ich denke, dass in Wirklichkeit viele Entwickler den fehlgeschlagenen Test überspringen.
___ answer361013 ___
Es gibt Gründe, Tests in TDD über die "Test-first" -Entwicklung hinaus zu schreiben.
Angenommen, Ihre Sortiermethode hat einige andere Eigenschaften, die über die Sortierung hinausgehen, z. B .: Sie bestätigt, dass alle Eingaben Ganzzahlen sind. Sie verlassen sich zunächst nicht darauf und es ist nicht in der Spezifikation, also gibt es keinen Test.
Später, wenn Sie dieses zusätzliche Verhalten ausnutzen möchten, müssen Sie einen Test schreiben, damit alle anderen, die mitkommen und Refactors, dieses zusätzliche Verhalten nicht brechen, auf das Sie sich jetzt verlassen.
___ answer478934 ___
Wie andere schon gesagt haben, lautet das Mantra von TDD "kein neuer Code ohne fehlgeschlagenen Unit-Test". Ich habe noch nie gehört, dass TDD-Praktizierende "keine neuen Tests ohne fehlenden Code" sagen. Neue Tests sind immer willkommen, auch wenn sie "zufällig" passieren. Sie müssen Ihren Code nicht ändern, um ihn zu unterbrechen, und ihn dann wieder ändern, um den Test zu bestehen.
___ tag123tdd ___ Test-Driven Development (TDD) beinhaltet das Schreiben eines fehlgeschlagenen automatisierten Tests, um anzugeben, was erstellt werden soll. Der Test wird dann durchgeführt, um einen Code zu schreiben, der die getestete Bedingung erfüllt. Schließlich wird der Code überarbeitet.
___ answer361054 ___
Aber was ist, wenn Ihr Code bereits die Situation berücksichtigt, die Sie testen möchten?
Bricht das das TDD-Mantra, immer fehlerhafte Tests zu schreiben?
Ja, weil Sie bereits das Mantra des Schreibens des Tests vor dem Code gebrochen haben. Sie könnten den Code einfach löschen und von vorn beginnen oder den Test einfach von Anfang an akzeptieren.
___ answer360878 ___
uh ... ich lese den TDD-Zyklus als
- schreibe zuerst den Test, der fehlschlägt, weil der Code nur ein Stub ist
- schreibe den Code so, dass der Test bestanden wird
- refactor wie nötig
Es besteht keine Verpflichtung, Tests zu schreiben, die fehlschlagen, der erste Fehler besteht darin, dass es keinen Code gibt, um irgendetwas zu tun. Der Punkt des ersten Tests ist, über die Schnittstelle zu entscheiden!
EDIT: Es scheint ein Missverständnis des Mantra "Rot-Grün-Refactor" zu geben. Laut wikipedia TDD-Artikel
Bei der testgesteuerten Entwicklung beginnt jedes neue Feature mit dem Schreiben eines Tests. Dieser Test muss zwangsläufig fehlschlagen, da er geschrieben wird, bevor das Feature implementiert wurde.
Mit anderen Worten, der Mist-Fail-Test ist für ein neues Feature , nicht für eine zusätzliche Abdeckung!
BEARBEITEN: es sei denn, Sie sprechen über einen Regressionstest, um natürlich einen Fehler zu reproduzieren!
___ antwort433370 ___
Das Beispiel, das Sie angegeben haben, ist IMO einer der richtigen Zeiten, um einen Test zu schreiben, der den ersten Versuch besteht. Der Zweck ordnungsgemäßer Tests besteht darin, das erwartete Verhalten des Systems zu dokumentieren. Es ist in Ordnung, einen Test zu schreiben, ohne die Implementierung zu ändern, um das zu erwartende Verhalten zu verdeutlichen.
P.S.
Wie ich es verstehe, ist hier der Grund, warum der Test fehlschlagen soll, bevor er bestanden wird:
Der Grund, warum Sie "einen Test schreiben, den Sie kennen, wird scheitern, aber testen Sie ihn, bevor Sie ihn bestehen" ist, dass die ursprüngliche Annahme, dass der Test mit Sicherheit fehlschlagen wird, falsch ist. In diesen Fällen hat der Test Sie davor bewahrt, unnötigen Code zu schreiben.
___ tag123failingtests ___ hilf uns dieses Wiki zu bearbeiten
___ answer478864 ___
Ich bin oft auf diese Situation gestoßen. Während ich TDD empfehle und versuche zu verwenden, unterbricht es manchmal den Fluss zu sehr, um zu stoppen und Tests zu schreiben.
Ich habe eine zweistufige Lösung:
- Sobald Sie Ihren Arbeitscode und Ihren nicht fehlgeschlagenen Test haben, fügen Sie absichtlich eine Änderung in den Code ein, damit der Test fehlschlägt.
- Schneiden Sie diese Änderung aus Ihrem ursprünglichen Code aus und fügen Sie ihn in einen Kommentar ein - entweder in der Code-Methode oder in der Testmethode. Wenn also jemand das nächste Mal sichergehen möchte, dass der Test Fehler erkennt, wissen sie, was zu tun ist. Dies dient auch als Beweis dafür, dass Sie das Fehlschlagen der Testaufnahme bestätigt haben. Wenn es am saubersten ist, lassen Sie es in der Code-Methode. Vielleicht möchten Sie sogar so weit gehen, die bedingte Kompilierung zu verwenden, um Testunterbrecher zu aktivieren.
___