Sehr oft werden die Vorteile der Verwendung von TDD als „langfristige“ Vorteile angesehen - der Gesamtcode ist besser strukturiert, besser testbar, insgesamt weniger von Kunden gemeldete Fehler usw.
Wo liegen jedoch die kurzfristigen Vorteile der Verwendung von TDD? Gibt es welche, die tatsächlich zugänglich und leicht messbar sind?
Ist es wichtig, einen offensichtlichen (oder gar nicht durch quantifizierbaren) kurzfristigen Nutzen zu haben, wenn die langfristigen Gewinne messbar sind?
Antworten:
TDD bietet einige kurzfristige Vorteile, von denen einige messbarer sind als andere. Hier sind einige von oben:
Reinigen Sie den Code nach den guten alten SOLID-Prinzipien . Wenn Sie Ihre Tests so sauber wie Ihren Code halten und schmutzigen Hybrid- Testcode vermeiden , folgt der Code in der Regel SOLID. Sauberer Code ist leichter zu lesen und es ist einfacher, Ihren Code von Anfang an zu pflegen. Während der Wartung werden Arbeitsstunden gespart, aber kurzfristig: Sie erhalten schneller saubereren Code (da Sie einige Tests haben, um Sie zu sichern).
Regressionstests von Anfang an; du hast es kaputt gemacht, du wirst es wissen ... früh. Dies wird von einem CI-Server unterstützt und erspart Ihnen einige Haare. Die Arbeitsstunden, um einen rückläufigen Fehler zu beheben, den Sie ohne Tests frühzeitig entdecken, sind schwer zu messen, aber sagen wir einfach, es sind viele Arbeitsstunden.
Ermöglicht das Refactoring ohne allzu viel Rätselraten. Wenn Sie eine Testsuite für eine Klasse erstellt haben, ist die Umgestaltung (z. B. Extrahieren von Methoden, Verwenden anderer Datenstrukturen, Extrahieren von Klassen) einfach, da Sie die Tests von Anfang an definiert haben. Was Tage dauern würde, um eine Klasse umzugestalten, wird weniger als eine dauern; und Sie können es sofort tun, wenn Sie die Tests von zuvor durchgeführt haben.
Mit testgetriebenem Design können Sie Codeduplizierungen frühzeitig beheben. Zumindest wenn Sie ein aufmerksamer Programmierer sind; weil das Testen mit doppeltem Code (sowohl im Testcode als auch im Produktionscode) schnell zu einer langweiligen Aufgabe wird. Je intelligenter Sie mit Ihrem Testcode sind, desto besser wird es. Weniger Code, weniger Aufwand, mehr Arbeitsstunden.
EDIT Auch hinzugefügt von Frank Shearar, dem ich zufällig zustimme:
Zu jedem Zeitpunkt haben Sie Arbeitscode (mit Ausnahme des Testfalls, mit dem Sie gerade arbeiten).
Das frühzeitige Erkennen von Fehlern oder Designproblemen durch TDD ist von unschätzbarem Wert und schwer zu messen, wie viel Sie in Arbeitsstunden sparen. Eine Möglichkeit wäre jedoch, die Stunden zu zählen, die Sie zuvor für die spätere Bearbeitung von Designproblemen aufgewendet haben. Mit Unit-Tests kann eine Teilmenge Ihres Codes durch Ihre Tests ausgeführt werden, ohne dass Sie Ihre eigentliche Anwendung oder Ihr System ausführen müssen. Auf diese Weise können Sie sich durch TDD versichern kann , dass ein Teil des Programms ist Arbeits Recht jetzt , auch wenn es zur Zeit nicht an der Realität angeschlossen werden kann.
Mit kurzfristig meinen Sie kleine Projekte oder die Anfänge eines Projekts?
Ich bin der Überzeugung, dass sich die Integration von Tests während der ersten Grundlagen sofort auszahlt, da Sie die Säulen überprüft haben, auf denen der gesamte Rest des Projekts stehen wird. Ich neige dazu, von oben nach unten zu entwerfen und von unten nach oben zu implementieren, daher ist dies für meine Arbeitsweise sinnvoll.
Wenn Sie jetzt sogar eine Inkonsistenz feststellen, hat sich Ihre Arbeit gerade bezahlt gemacht, da Sie später kein komplexeres Programm debuggen müssen.
Außerdem ist Ihr Projekt bereits zum Testen eingerichtet und Sie müssen später kein Rig mehr umbauen.
Ein sehr kurzfristiger Vorteil von TDD ist, dass ich mich nicht so sehr auf das konzentrieren muss, was ich erreichen möchte.
Wenn ich von meiner Arbeit unterbrochen werde, dauert es ohne TDD einige Minuten, um mich daran zu erinnern, wo ich bin, wenn ich wieder zur Aufgabe zurückkomme.
Mit TDD führe ich einfach die Tests durch, um festzustellen, welcher fehlschlägt, und weiß sofort, was ich erreichen wollte. Ich arbeite schneller mit weniger Gehirnschmerzen.