Hier sind drei Gründe, warum TDD einem Entwickler / Team helfen könnte:
Ein Grund, die Tests zuerst zu schreiben, besteht darin, dass Sie den tatsächlichen Code besser verstehen, bevor Sie ihn schreiben. Das ist für mich der Hauptvorteil der testgetriebenen Entwicklung. Wenn Sie zuerst die Testfälle schreiben, denken Sie kritischer über die Eckfälle nach. Es ist dann einfacher, sie anzugehen, wenn Sie den Code schreiben und sicherstellen, dass sie genau sind.
Ein weiterer Grund besteht darin, die Tests tatsächlich zu erzwingen. Wenn Menschen Unit-Testing ohne TDD durchführen, wird oft ein Testframework eingerichtet, ein neuer Code geschrieben und dann beendet. Sie denken, dass der Code schon gut funktioniert, warum also Tests schreiben? Es ist einfach genug, dass es nicht bricht, oder? Aber jetzt haben Sie die Vorteile von Komponententests an erster Stelle verloren (ganz andere Diskussion). Schreibe sie zuerst, und sie sind schon da.
Das Schreiben dieser Tests könnte bedeuten, dass Sie das Programm nicht in einer Debugging-Umgebung starten müssen (langsam - insbesondere bei größeren Projekten), um zu testen, ob ein paar kleine Dinge funktionieren. Natürlich gibt es keine Entschuldigung dafür, dies nicht zu tun, bevor Änderungen vorgenommen werden.
Es kann schwierig sein, sich selbst oder andere zu überzeugen, die Tests zuerst zu schreiben. Sie haben vielleicht mehr Glück, wenn Sie beide zur gleichen Zeit schreiben, was genauso vorteilhaft sein kann.
Vermutlich testen Sie Code, den Sie geschrieben haben, bevor Sie ihn in ein Repository schreiben.
Wenn das nicht stimmt, haben Sie andere Probleme zu bewältigen.
Wenn es zutrifft, können Sie sich das Schreiben von Tests mithilfe eines Frameworks ansehen, um die Hauptroutinen oder Treiber, die Sie gerade schreiben, zu automatisieren, sodass Sie alle auf Knopfdruck automatisch ausführen können. Sie müssen nicht über die Ausgabe blättern, um zu entscheiden, ob der Test erfolgreich war oder fehlgeschlagen ist. Sie betten den Erfolg oder Misserfolg des Tests in den Code ein und erhalten sofort eine Daumen hoch oder runter Entscheidung. Das Ausführen aller Tests auf einmal reduziert die Wahrscheinlichkeit einer Situation, in der Sie etwas in einer Klasse reparieren und etwas anderes kaputt machen. Alle Tests müssen bestanden werden.
Klingt soweit gut, ja?
Die TDD-Leute gehen einfach einen Schritt weiter und fordern, dass Sie den Test FIRST schreiben, bevor Sie die Klasse schreiben. Es scheitert natürlich, weil Sie die Klasse nicht geschrieben haben. Es ist ihre Art zu garantieren, dass Sie Testklassen schreiben.
Wenn Sie bereits ein Testframework verwenden, einen guten Wert aus den von Ihnen geschriebenen Tests ziehen und eine sinnvolle Codeabdeckung von etwa 70% haben, dann ist es Ihrer Meinung nach gut. Ich bin nicht sicher, dass TDD Ihnen viel mehr Wert geben wird. Es liegt an Ihnen zu entscheiden, ob Sie diese Extrameile gehen oder nicht. Persönlich mache ich es nicht. Ich schreibe Tests nach der Klasse und Refactor, wenn ich das Bedürfnis verspüre. Manche Leute finden es vielleicht hilfreich, den Test zuerst zu schreiben, weil er weiß, dass es scheitern wird, aber ich tue es nicht.
(Dies ist eher ein Kommentar, der der Antwort von Duffymo entspricht, als eine eigene Antwort.)
duffymo antwortet:
Die TDD-Leute gehen einfach einen Schritt weiter und fordern, dass Sie den Test FIRST schreiben, bevor Sie die Klasse schreiben. Es scheitert natürlich, weil Sie die Klasse nicht geschrieben haben. Es ist ihre Art zu garantieren, dass Sie Testklassen schreiben.
Ich denke, dass es die Programmierer zwingt, darüber nachzudenken, was ihr Code macht. Wenn man über einen Test nachdenkt, denkt man darüber nach, was der Code tun soll: Was sind die Vorbedingungen und Nachbedingungen, welche Funktionen sind primitiv und welche bestehen aus primitiven Funktionen, was ist die minimal notwendige öffentliche Schnittstelle und was ist das? ein Implementierungsdetail.
Das sind alles Dinge, an die ich routinemäßig denke, so wie du, "test first" fügt nicht viel hinzu, für mich . Und ehrlich gesagt (ich weiß, das ist in einigen Kreisen Häresie) mag ich es, die Kernideen einer Klasse zu "verankern", indem ich zuerst die öffentliche Schnittstelle skizziere; So kann ich es ansehen, es geistig benutzen und sehen, ob es so sauber ist, wie ich es dachte. (Eine Klasse oder eine Bibliothek sollte für Client-Programmierer einfach und intuitiv zu verwenden sein.)
Mit anderen Worten, ich tue, was TDD zu erreichen versucht, indem ich Tests zuerst schreibe, aber wie Duffymo komme ich da anders hin.
Und der wahre Sinn von "test first" ist, einen Programmierer dazu zu bringen, innezuhalten und wie ein Designer zu denken. Es ist albern, einen Fetisch davon zu machen, wie der Programmierer in diesen Zustand eintritt; Für diejenigen, die es nicht auf natürliche Weise tun, dient "test first" als ein Ritual, um sie dorthin zu bringen. Für diejenigen, die das tun, "testet zuerst" fügt nicht viel hinzu - und kann dem gewohnten Weg des Programmierers in diesen Zustand im Weg stehen.
Auch hier wollen wir Ergebnisse betrachten, keine Rituale. Wenn ein Jugendlicher ein Ritual braucht, eine "Kreuzwegstation" oder einen Rosenkranz, um "in den Groove zu kommen", dann dient "test first" diesem Zweck. Wenn jemand auch seinen eigenen Weg hat, ist das auch toll.
Beachten Sie, dass ich nicht sage, dass der Code nicht getestet werden sollte. Es sollte. Es gibt uns ein Sicherheitsnetz, das es uns wiederum ermöglicht, unsere Aufmerksamkeit darauf zu konzentrieren, guten Code, sogar kühnen Code zu schreiben, weil wir wissen, dass das Netz Fehler finden kann.
Alles was ich sage ist, dass fetischistisches Beharren auf "test first" die Methode (eine von vielen) mit dem Ziel verwechselt und den Programmierer darüber nachdenkt, was er programmiert .
* Um ökumenisch zu sein, werde ich feststellen, dass sowohl Katholiken als auch Muslime Rosenkränze benutzen. Und wieder, es ist ein
Idealerweise:
Sie werden keine Zeit damit verschwenden, Funktionen zu schreiben, die Sie nicht brauchen. Sie erhalten eine umfassende Einheitentestsuite, die als Sicherheitsnetz für das Refactoring dient. Sie haben ausführbare Beispiele, wie Ihr Code verwendet werden soll. Ihr Entwicklungsablauf wird reibungsloser und schneller; Sie werden weniger Zeit im Debugger verbringen.
Aber vor allem wird Ihr Design besser sein. Ihr Code wird besser berücksichtigt - lose gekoppelt, sehr zusammenhängend - und besser geformt - kleinere, besser benannte Methoden & amp; Klassen.
Für mein aktuelles Projekt (das in einem relativ schwergewichtigen Prozess läuft) habe ich eine spezielle Form von TDD übernommen, die aus dem Schreiben von Skelett-Testfällen besteht, die auf Anforderungsdokumenten und GUI-Modellen basieren. Ich schreibe Dutzende, manchmal Hunderte, bevor ich mit der Implementierung von irgendetwas beginne (das läuft völlig gegen "reine" TDD, die besagt, dass man ein paar Tests schreiben sollte, dann sofort mit einer Skeleton-Implementierung beginnen).
Ich habe festgestellt, dass dies eine hervorragende Möglichkeit ist, die Anforderungsdokumente zu überprüfen. Ich muss viel intensiver über das in ihnen beschriebene Verhalten nachdenken, als wenn ich sie nur lesen würde. Folglich finde ich in ihnen viel mehr Widersprüche und Lücken, die ich sonst nur bei der Umsetzung gefunden hätte. Auf diese Weise kann ich um eine frühere Klärung bitten und bessere Anforderungen haben, wenn ich mit der Umsetzung beginne.
Dann sind die Tests während der Implementierung eine Möglichkeit zu messen, wie weit ich noch gehen muss. Und sie hindern mich daran, irgendetwas zu vergessen (lach nicht, das ist ein echtes Problem, wenn du an größeren Anwendungsfällen arbeitest).
Und die Moral ist: Selbst wenn Ihr Entwicklungsprozess TDD nicht wirklich unterstützt, kann es immer noch auf eine Art und Weise durchgeführt werden und Qualität und Produktivität verbessern.
Ich persönlich benutze TDD nicht, aber eines der größten Pros, das ich mit der Methodik sehen kann, ist die Kundenzufriedenheitsgarantie . Im Grunde ist die Idee, dass die Schritte Ihres Entwicklungsprozesses diese sind:
1) Sprechen Sie mit dem Kunden darüber, was die Anwendung tun soll und wie sie auf verschiedene Situationen reagieren soll.
2) Übersetze das Ergebnis von 1) in Unit-Tests, die jeweils ein Feature oder Szenario testen.
3) Schreiben Sie einfachen, "schlampigen" Code, der (kaum) die Tests besteht. Wenn dies erledigt ist, haben Sie die Erwartungen Ihres Kunden erfüllt.
4) Refaktorieren Sie den Code, den Sie in 3 geschrieben haben, bis Sie denken, dass Sie es auf die effektivste Weise getan haben.
Wenn Sie damit fertig sind, haben Sie hoffentlich qualitativ hochwertigen Code produziert, der den Bedürfnissen Ihrer Kunden entspricht. Wenn der Kunde jetzt ein neues Feature möchte, starten Sie den Zyklus über - diskutieren Sie das Feature, schreiben Sie einen Test, der sicherstellt, dass es funktioniert, schreiben Sie Code, der den Test besteht, refactor.
Und wie andere gesagt haben, stellen Sie bei jeder Ausführung Ihrer Tests sicher, dass der alte Code immer noch funktioniert und dass Sie neue Funktionen hinzufügen können, ohne die alten zu zerstören.
Ich habe große Anstrengungen unternommen, TDD für die Entwicklung von Ruby on Rails zu lernen. Es hat einige Tage gedauert, bis ich wirklich dazu gekommen bin. Ich war sehr skeptisch, aber ich habe mich bemüht, weil Programmierer, die ich respektiere, es unterstützen.
Ich denke, dass es sich auf jeden Fall gelohnt hat. Es gibt einige Vorteile, von denen andere sicher gerne für Sie auflisten werden. Für mich ist der wichtigste Vorteil, dass es hilft, diese Albtraumsituation spät in einem Projekt zu vermeiden, wo plötzlich etwas ohne ersichtlichen Grund bricht und man dann anderthalb Tage mit dem Debugger verbringt. Es hilft zu verhindern, dass sich Ihre Codebasis verschlechtert, wenn Sie mehr und mehr Logik hinzufügen.
TDD (Test Driven Development / Design) bietet die folgenden Vorteile
Als Ergebnis erhalten Sie einen Code, der
istEs ist allgemein bekannt, dass Schreiben von Tests und eine große Anzahl von automatisierten Tests eine gute Sache sind.
Ohne TDD wird es jedoch oft nur mühsam. Die Leute schreiben Tests und verlassen sie dann, und die Tests werden nicht so aktualisiert, wie sie sollten, und neue Features werden auch nicht so oft getestet, wie sie sollten.
Ein großer Teil davon ist, dass der Code zu einem schmerzhaften Test geworden ist - TDD wird Ihren Entwurf beeinflussen, so dass es viel einfacher ist zu testen. Da Sie TDD verwendet haben, haben Sie eine gute Anzahl an Tests, was es erleichtert, Regressionen zu finden, wenn sich Ihr Code oder Ihre Anforderungen ändern, was das Debugging dramatisch vereinfacht, gute TDDs wertschätzt und bei Änderungen zu mehr Tests motiviert benötigt - und wir sind zurück zum Anfang des Zyklus.
Äh, Höhere Codequalität ? Weniger Fehler? Weniger verschwendete Zeit?
Wählen Sie Ihre ...
Tags und Links unit-testing tdd agile