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.

herzlich Wilkommen auf Dead Bytes.

Dead Bytes – das ist mein persönliches Blog zu allen Themen, die mit meinem Studium oder meiner Arbeit zusammenhängen. Hauptsächlich wird es also in die Bereiche Softwareentwicklung, Softwarequalitätssicherung, Webentwicklung und Software Engineering gehen. Aber auch sonst werde ich wohl, wenn ich über ein IT Thema stolpere, gerne hier posten.

Politische IT-Themen (Netzsperren and whatnot) werde ich aber weiterhin auf dem Hömmel kommentieren. Für diejenigen, die das noch nicht kennen: Das Hömmel ist das ultimative Blog, in dem Jesus und die Linke&rechte Hand des Teufels einfach quasi über alles reden.

Übrigens, alle die Global Destruction suchen und verwirrt sind: Kai hat mir diese Domain, die er ja eh schon lang los werden wollte, dankbarerweise recht günstig überlassen. Das hat uns beiden was gebracht: Er ist die Domain los und ich muss nicht so viel nachdenken, wie ich meinen Blog nenne. GD ist also nicht mehr über diese Adresse erreichbar, aber natürlich wie immer noch unter http://www.global-destruction.de.

Aber zurück zu Dead Bytes:

Politische Meinungen und hitzige Sozialdebatten werde ich hier keine führen. Hier ist Raum für IT.

Ich könnte mir auch vorstellen, den ein oder anderen Gastbeitrag hier zu veröffentlichen, wenn jemand keine Lust hat, sein eigenes IT-Blog zu starten

Das ist so grob zusammengefasst mein Konzept für Dead Bytes. Wir sind gespannt, obs was wird.

Nachtrag: Es sei noch erwähnt, dass GD leider nur noch bis Ende Januar unter der genannten Adresse zu finden sein wird und dann vom Netz geht,