Dies ist eine kurze Antwort auf den Beitrag „Wie viel Sinn machen Unit Tests?“ von Golo Roden. Ich möchte mir zunächst ein paar pikante Stellen herauspicken:
„Daher empfinde ich es zumindest als bedenklich, ein durchdachtes, objektorientiertes und sauberes Design zu Gunsten einer besseren Testbarkeit zu ändern, wenn es dafür keine weiteren Gründe gibt.“
Meine Erfahrung lautet: ein vernünftiges Design läuft Testbarkeit nicht zuwider. Sondern das Gegenteil ist der Fall: durch den Zwang, Code in völlig autonome Einheiten (Units) packen zu müssen (denn Unit Tests sollen schließlich unabhängig von einander lauffähig sein und keine Abhängigkeiten besitzen) wird man als Entwickler automatisch dazu gezwungen, sich mit seinem Code intensiv auseinanderzusetzen und in der Konsequenz vor allem auch Abhängigkeiten aufzulösen bzw. gar nicht erst entstehen zu lassen.
Im Ergebnis erhält man bei konsequenter Anwendung oft eine wesentlich besser gestaltete Anwendung als man sie ohne Tests bekommen hätte, schon alleine deshalb, weil man sich zur Durchführung der Tests um jede kleine Komponente bereits vor ihrer Erstellung Gedanken machen muss.
„Natürlich können all diese Abhängigkeiten entfernt, umgangen oder verschleiert werden – die Frage ist aber, zu welchem Preis dies geschieht. Es genügt nämlich nicht, Stubs und Mocks einzuführen, statt dessen muss die Umgebung auch nach jedem Test potenziell wieder zurückgesetzt werden: Schließlich soll jeder Test isoliert, das heißt unabhängig von seinen Vorgängern, ausgeführt werden.„
Es ist in der Praxis auch selten notwendig mit echten Daten aus einer Datenbank zu hantieren, diese können einfach gefälscht werden, beispielsweise durch den Einsatz des Mocking-Frameworks Rhino Mocks.
„Auch die Abhängigkeit von der Laufzeitumgebung an sich kann problematisch sein. So können sich beispielsweise HTTP-Anforderungen, die an eine Webanwendung gesendet werden, voneinander unterscheiden – je nachdem, welcher Webbrowser auf dem Client eingesetzt wird.“
Hier kommen wir wieder zurück zum ersten Punkt: durch den konsequenten Einsatz von Tests wird man automatisch zu loser Koppelung gezwungen. Ein direkter Zugriff auf HttpContext.Current in einer Webanwendung verbietet sich nun schon deshalb, weil dieser bei Ausführung der dazugehörigen Tests immer null ist. Die Folge: man kapselt diese Zugriffe, wie übrigens auch solche aufs Filesystem oder die Windows-Registry, und arbeitet in seinem Code nur gegen Interfaces. Während der Testphase werden die jeweiligen Objekte einfach gemockt.
Ich fühle mich nun nicht zum Missionar für Test Driven Development berufen, kann aber aus fast (nur) einjähriger eigener Praxis-Erfahrung sagen, dass es sich für mich persönlich gelohnt hat, auf den Zug aufzuspringen und TDD konsequent in meinen Projekten einzusetzen.
Hier habe ich natürlich nicht in den berühmten „Brown-Field“-Projekten angesetzt, sondern mir gezielt neue „Green-Field“-Projekte gesucht, in denen der konsequente Einsatz von TDD nicht durch bestehenden Code und damit unauflösbare Abhängigkeiten gestört wurde.
In dieser Zeit habe ich nicht nur noch bewusster entwickelt und meinen Code entworfen, als ich es vorher schon tat, sondern letztendlich auch einen ganz messbaren Benefit daraus gezogen: zwar kostete mich der Einsatz von TDD zu Beginn sehr viel mehr Zeit, allerdings wurde dies bereits im ersten Projekt (ASP.NET MVC, ca. 4 Mannwochen und 400 Unit-Tests) dadurch belohnt, dass nach einem halben Jahr im Live-Betrieb kein einziger Fehler gemeldet wurde. Die Zeiten von Bananen-Software („reift beim Kunden“) sind also endgültig vorbei.
Heute ertappe ich mich bei Change Requests in diesen Projekten zwar noch ab und zu dabei, diese ohne Tests einbauen zu wollen, im Großen und Ganzen habe ich das Thema TDD aber verinnerlicht und bin auch froh darüber. Der anfänglich immens erscheinende Mehraufwand an Zeit hat sich inzwischen auch längst relativiert - und das bisschen mehr, was an Zeit nötig ist, ist mir der durchdachtere und fehlerfreiere Code wert.
P.s.: Ich weiß wie schwer der Anfang bei TDD ist, daher sei an dieser Stelle noch einmal auf den hervorragenden Webcast „Introduction to Test Driven Development“ (auf Deutsch) von Gabriel Schenker verwiesen.
