Test-Driven-Design (TDD) ist ein heißes Thema und kaum ein Entwickler kommt mehr daran vorbei. War dieses Feld zunächst nur von Bedeutung in Projekten, die hoch-kritische Prozesse zum Gegenstand hatten, wie sie für Banken, Kernkraftwerke oder gar den Start einer Ariane-Rakete typisch sind, führte die Integration von TDD-Tools in populäre Entwicklungssysteme bald zu einer teilweise auch modischen Verbreitung.
TDD-Tools müssen nicht wirklich in jedem Projekt eingesetzt werden. Vor allem die reine Lehre führt schnell zu einem zusätzlichen Aufwand für das Schreiben von Tests, der nicht immer wirtschaftlich ist.
Die Theorie verlangt, dass vor jeder Funktion, die geschrieben werden soll, erst die zugehörigen Tests entwickelt werden. Dies erfordert viel Disziplin vom Entwickler, die Kenntnis hochentwickelter Testverfahren (Mocking) und das Vorhandensein von sehr viel zusätzlicher Entwicklerzeit. Der Ansatz verspricht, dass dieses Mehr an Entwickleraufwand später wieder hereingeholt wird durch sehr viel weniger Aufwand beim Debuggen.
In der Praxis wird heute aber auch ein weniger fundamentalistischer Ansatz akzeptiert, natürlich nur dann, wenn es nicht um hochkritische Projekte, wie einen Raketenstart, geht. Viele Entwickler haben sich zudem Gedanken gemacht, wie man entsprechende Tools komfortabel in den eigenen Workflow integrieren kann.
Nach einigem Probieren habe ich für mich für die Frontend-Entwicklung das Jasmine-Framework (Behavior driven Javascript) als Unit-Testing-Tool entdeckt, das per Grunt sehr einfach in den eigenen Workflow integrierbar ist.
