Test Driven Development (TDD) ist ein Thema, dass Entwickler polarisiert (jedenfalls in meiner Erfahrung).
Nochmal für alle, die es vergessen haben: TDD lässt sich kurz beschreiben: Statt (wie es klassisch üblich ist) erst den Quellcode zu schreiben und diesen dann zu testen, wird beim TDD zuerst der Testfall geschrieben. Der schlägt natürlich fehl. Dann wird erst die Implementierung geschrieben und zwar so lange, bis der Testfall nicht mehr fehlschlägt. Die Intention dahinter ist natürlich, dass sichergestellt wird, dass das getestete Objekt nachher auch nur das tut, was sie soll und dass es vollständig getestet wird.
Besonders bei Komponententests wird ja gerne ein White-Box-Verfahren angewandt. Auch wenn natürlich gerade JUnit als berühmtester Vertreter der Frameworks für Modul- und Integrationstests ursprünglich für TDD geschrieben wurde, bevorzugen viele Entwickler für diese Teststufe den implementierten Code zu testen und eben nicht TDD anzuwenden. Der vermeintliche Vorteil: Man weiß, welche Fehlerbehandlung getestet werden muss, weil diese ja bereits implementiert wurde (offensichtlich). Das ist allerdings ein Trugschluss, denn wenn die getestete Funktion von vorne herein gut designed wurde, sollte ja wohl schon vorher klar sein, welche Fehler behandelt werden sollten.
Wenn es richtig angewendet wird, zwingt TDD den Entwickler ja förmlich dazu, sich vorher Gedanken über das zu machen, was er entwickeln will und besonders darüber, wie es funktionieren muss.
Übrigens lässt sich das auch wunderbar mit requirementbasiertem Testen vereinbaren, wie es z.B. der in der Luftfahrt geforderte DO-178B Standard vorsieht, vereinbaren. In diesem Fall müsste natürlich das Low-Level-Requirement noch vor dem Test geschrieben werden. Aber dann kann man den Test nach dem Requirement modeln und schließlich das Requirement implementieren.
Provokativ gesagt: Eigentlich funktioniert TDD überall da, wo die Entwickler nicht zu faul sind, sich vorher Gedanken zu machen.
