Ich schätze TDD und denke, dass es unentbehrlich ist, aber schreibe meine Tests NUR, nachdem ich meinen Quellcode geschrieben habe, um dann entsprechend zu refaktorieren. Ich kann mich nie dazu bringen, zuerst den Test zu schreiben, dann die Quelle, um den Test zu bestehen. Also mache ich den Prozess immer rückgängig. Ist das eine schlechte Übung für mich? Was sind die Nachteile, es umgekehrt zu machen wie ich?
Wenn Sie Ihre Tests nicht zuerst schreiben, dann ist es wohl kein TDD. Mit TDD schreiben Sie normalerweise den Test, sehen Sie, wie er fehlschlägt, und implementieren Sie ihn, um ihn zu bestehen.
Die Vorteile gegenüber Ihrem Workflow sind:
Sie können die Risiken all dieser Punkte mindern, also liegt es an Ihnen, ob Sie weitermachen wollen oder zuerst zum Test wechseln.
Wenn Sie die Tests anschließend schreiben, treiben sie wirklich die Entwicklung / das Design? Ich würde nicht denken.
Um Steven Robbins 'Antwort zu erweitern: Wenn dein Test nicht fehlschlägt, bevor du ihn bestanden hast, woher weißt du, dass er das Richtige testet ? ? ?
Das Nachdenken über Ihr Software-Design und die dazugehörige Kodierung folgten genau, indem Sie Tests hinzufügten, um sicherzustellen, dass Sie etwas nicht vergessen haben, ist eine gute Möglichkeit, in meinem Buch fortzufahren.
Sie denken über Ihren Code sowohl von einem Softwaredesign als auch von einem Teststandpunkt nach. Ich tendiere dazu, parallel Code zu entwickeln und zu testen, folge niemals dem Paradigma "Schreibe deinen Test zuerst", weil es tendenziell zu Code führt, der deine Tests erfüllt - nicht dein Design.
Das Risiko bei TDD besteht darin, dass die Designphase weggelassen wird. Wenn Sie Ihre Tests erstellen, die versuchen, Ihren Code auf jede mögliche Art und Weise zu brechen, dann beheben Sie die Probleme, die Ihr Test mit sich bringt, erhalten Sie stabilen Code. Ich musste Code umschreiben, der über TDD geschrieben wurde, der bestenfalls Prototypqualität hatte, es ist nicht die Methode, die guten Code liefert, es ist die mentale Anstrengung, die man hineingesteckt hat.
Wird das Design von den Testüberlegungen bestimmt? Wenn dem so ist, dann hat das Testen die Entwicklung vorangetrieben. Was soll passieren?
Das Schreiben von Tests stellt absolut sicher, dass Tests die Entwicklung vorangetrieben haben. Und es begrenzt das Refactoring.
Wenn Sie den gesamten Code zuerst schreiben und dann umgestalten möchten, verwenden Sie Tests, um die Entwicklung voranzutreiben (was gut ist). Allerdings verschwenden Sie wahrscheinlich Zeit, indem Sie zunächst den gesamten Code schreiben, um ihn später alle zu refaktorisieren (was nicht so gut ist.) Die Verwendung von TDD wird dies erleichtern; Das Schreiben von Tests vor dem Code wird auch die Entwicklungszeit verkürzen, indem man etwas Refactoring spart.
Ich mache seit 2000 TDD (richtig). Es gibt viele gute Punkte, die andere erwähnt haben, aber ein Punkt, der sehr wichtig ist und in den anderen Beschreibungen fehlt:
>TDD lässt Sie einfachen Code schreiben!
Wenn Sie TDD schreiben, schreiben Sie den Test und schreiben dann den absolut einfachsten möglichen Code, um den Test zu bestehen. Wenn Sie das umkehren, schreiben Sie oft Code, der komplexer ist als er sein muss und der unbeabsichtigte Nebenwirkungen hat.
TDD ist eine sehr schwierige Disziplin, aber es ist wichtig, weil es vergleichbar ist mit einem Chirurgen, der seine Instrumente vor der Operation sterilisiert. Wenn Sie nicht sterilisieren, riskieren Sie, Ihren Patienten zu infizieren. Wenn Sie Ihren Test nicht zuerst schreiben, riskieren Sie, Ihren Code mit technischen Schulden zu infizieren.
Tags und Links language-agnostic testing tdd