Ich habe gerade erst entdeckt, wie viel Spaß es macht, den TDD-Code zu entwickeln: Ich habe das Gefühl, viel mehr Kontrolle darüber zu haben, in welche Richtung die Entwicklung geht. Während ich zuvor viel Zeit damit verbracht habe, Datenstrukturen und Algorithmen zu entwerfen, beginne ich jetzt klein und "entwickle" meinen Code organisch. Nach jedem Rot / Grün / Refaktor-Zyklus habe ich Code, der etwas tut. Es fühlt sich an, als ob mein Code ein lebendes Ding ist und ich leite, wo es wachsen soll. Ich weiß nicht, ob sich alle so fühlen, wenn sie in TDD kommen, aber das ist meine Erfahrung. Und es fällt mir auf, dass dies so ähnlich ist, wie erfolgreiche freie Software-Projekte eher entwickelt als entworfen werden.
Aber jetzt, wo ich an der Test-getriebenen Entwicklung festhalte, frage ich mich langsam, was seine Grenzen sind. Es scheint sehr nützlich für die Entwicklung von Funktionscode zu sein: füttere diesen Eingang mit dieser Funktion, und du erhältst dieses Ergebnis. Aber das ist nur ein kleiner Teil dessen, worum es bei der Softwareentwicklung geht. Was ist mit GUI-Entwicklung, Vernetzung, Datenbankentwicklung, Web-Anwendungen? Was ist deine Erfahrung? Haben Sie jemals TDD mit einer dieser Arten von Entwicklung versucht? Kennen Sie irgendwelche Tools oder Frameworks? Kannst du irgendwelche Artikel oder Bücher empfehlen?
"Was ist mit GUI-Entwicklung, Netzwerk, Datenbankentwicklung, Web-Anwendungen?"
Warum würde es nicht funktionieren?
Benutzeroberfläche . Das einzige, was TDD nicht gut machen kann, ist das "Aussehen" der Schnittstelle zu bewerten. Aber es kann das Verhalten auswerten. Wenn Sie Ihr Design gut gemacht haben (Trennen von Modell, Ansicht und Kontrolle), können Sie das Steuerelement und Modell einfach als TDD testen. View ist jedoch schwieriger zu schreiben Tests für. ("Bestätigen, dass der Knopf unter dem Feld ist" ist nicht sinnvoll.)
Netzwerk . Nicht sicher, was das bedeutet. Die Definition von RESTful-Webdiensten funktioniert jedoch sehr gut, wenn sie über TDD erfolgt. Definieren Sie die URIs, schreiben Sie Testfälle, und erstellen Sie dann die Dienste, die die erwarteten Antworten bereitstellen.
Web-Anwendungen . Das Django-Web-Framework unterstützt TDD direkt für die Entwicklung. Sie haben Komponententests für das Webdatenmodell und die Steuerungsebenen. Außerdem haben sie Komponententests für die Präsentation und das Verhalten der HTML-Seite.
Ich frage mich, welchen Rahmen / welche Sprache Sie für Ihre TDD verwenden, wenn Sie noch nicht die offensichtlichsten Teile davon getroffen haben, wo es schwierig ist:
GUIs - Bestimmte Umgebungen und Plattformen, insbesondere Windows Forms und ASP.NET-Webformulare, leiden unter der praktischen Untestabilität, da es keine einfache Möglichkeit gibt, ihr Verhalten zu isolieren oder zu verspotten. Dies ist eine der Hauptantriebskräfte von ASP.NET MVC, für diese Angelegenheit.
Persistenz - Jede Art von Persistenz, sei es Festplattenspeicher, Verbindung zu einer Datenbank, zu einem Netzwerk oder eine andere Form eines externen Systems, wäre eine Einschränkung, wie alle anderen es sind Persistenztests, die zu sehr vom Zustand einer externen Komponente abhängen, um erfolgreich zu sein. Diese Integrationstests gelten dann als fragile Tests . Mocking wird verwendet, um die Auswirkungen solcher externer Systeme zu mindern.
Adoption - Auch wenn Sie mit TDD vertraut sind, ist es ein harter Kampf, andere Entwickler - und noch viel weniger ganze Entwickler-Shops - dazu zu bringen, sie zu nutzen. Viele sehen den Vorteil einfach nicht; Sie werden durch die anfänglichen steilen Lern- und Produktivitätskurven leicht ausgeschaltet. Sie werden Fälle antreffen, in denen Sie als einziger TDD in Ihrem Projekt praktizieren, und selbst wenn Sie es durchsetzen, werden die anderen Entwickler minderwertige, sinnlose Tests einführen. Dieser nicht-technische Grund ist die größte Hürde für die Verwendung von TDD in realen Produktionssystemen, mit denen ich konfrontiert war, und es ist eine schmerzhafte Erkenntnis, wenn Sie sich der Vorteile bewusst sind.
Sie haben einige Kosten TDD zu tun:
Ich mag TDD für viele Dinge. Beachten Sie, dass die oben genannten Wartungskosten für das Führen von Tests für Arbeitseinheiten dazu führen können, dass Ihr modularer Aufbau zwar schwieriger zu gestalten ist, die gewählte modulare Organisation jedoch schwieriger zu ändern ist. Sie können Ihren Code nicht ohne zusätzliche Kosten für das Umschreiben aller Komponententests neu organisieren. Das ist wirklich das große Limit, das ich mit TDD gefunden habe. Später, wenn du erkennst, dass du einen Fehler gemacht hast, hast du jetzt all diesen Overhead, den du durchmachen musst, um die Dinge umzuformen, während vorher diese Veränderungen viel flüssiger passieren konnten. Um TDD gut zu nutzen, würde ich sagen, dass Sie gute Entscheidungen treffen müssen, wenn Sie das Modul zum ersten Mal entwickeln. Nicht immer einfach in der sich verändernden, agilen Welt, in der wir leben;).
Bedenke auch:
Was die Grenzen anbelangt, ist es wichtig, daran zu denken, dass es bei TDD um Stabilität und Verwaltung von Änderungen geht - es hilft Ihnen wahrscheinlich nicht besonders, besser zu gestalten erzwingt nur die Implementierung Ihres Designs *. Um eine gute Systemarchitektur zu entwickeln, bedarf es immer noch so viel Nachdenken wie bei jeder anderen Dev-Methode.
Es gibt eine Vielzahl von Limits, die meisten davon, weil Software immer noch Menschen benötigt:
* Auch wenn ich das geschrieben habe, bin ich mir nicht sicher, wie ich das richtig formulieren soll.
Probieren Sie groovy auf Grails. Sie erhalten automatisch generierte Tests.
Jedes Mal, wenn Sie eine Controller-Klasse automatisch erstellen, wurde eine Unit-Test-Klasse generiert.
Aus dem Buch "Der definitive Leitfaden für Grals":
Grails trennt Tests in "Unit" - und "Integration" -Tests. Integrationstests Bootstrap die gesamte Umgebung einschließlich der Datenbank und daher tendenziell langsamer laufen. In Ergänzung, Integrationstests werden typischerweise entwickelt, um die Interaktion zwischen einer Anzahl von Klassen und Daher benötigen Sie eine vollständigere Anwendung, bevor Sie sie ausführen können. Unit-Tests hingegen sind schnell laufende Tests, die Sie jedoch umfangreich durchführen müssen Verwendung von Mocks und Stubs. Stubs sind Klassen, die beim Testen verwendet werden und das reale Verhalten von Methoden durch Rückgabe von willkürlich fest codierten Werten. Mocks machen im Wesentlichen dasselbe, aber Zeige etwas mehr Intelligenz, indem du "Erwartungen" hast. Zum Beispiel kann ein Mock das spezifizieren Es "erwartet", dass eine bestimmte Methode mindestens einmal oder bei Bedarf sogar zehn Mal aufgerufen wird.
Tags und Links tdd