Für mich wirken Softwareprojekte, in denen nicht testgetrieben entwickelt wird, wie Artefakte aus der Steinzeit. Erinnert ihr euch an die Zeit, in der es noch keine Gurtpflicht im Auto gab? Kaum zu glauben, oder? Ich fühle mich ohne TDD etwa genauso wie heute ohne angelegten Gurt.
Am Dienstag, den 24. Juni 2014, durfte ich einen Vortrag über meine Erfahrungen mit Test Driven Development (TDD) halten. Summa-Summarum habe ich dort eine Lanze für TDD gebrochen.
Meine Kernbehauptung war, dass TTD die "Silver Bullet" des Softwareengineering sein kann, sofern man richtig "zielen" kann und die passenden "Waffen" einsetzt. Man sollte verstehen, wie TDD funktioniert und mit welchen Mitteln das am besten geht.
Wenn's euch interessiert, hier sind die Folien.
Interessant fand ich auch, dass von zwanzig Teilnehmern grade mal zwei an ihrem Arbeitsplatz TDD einsetzen. Immerhin gibt es das Thema schon einige Zeit (aber ihr werdet kaum glauben, wie alt TDD ist). Wäre interessant mal zu untersuchen, woran das liegt. Vielleicht sind die Gründe ähnlich den unsrigen - wir wussten einfach nicht, wie man TDD richtig macht. Oder es liegt vielleicht daran, dass die Entscheider keinen Mehrwert erkennen können. Naja, wer das Problem hat, kann sich ja mal meine Folien ansehen, da ist der Mehrwert wohl kaum zu übersehen.
Der Vortrag hat im Rahmen des Arbeitskreises "Software Engineering Live" der GI/GChACM-Regionalgruppe München stattgefunden. Hier ist der Teaser dazu:
Thema: Praxiserfahrungen mit Test Driven Development
Referent: Michael Karneim, Sanacorp GmbH
In diesem Vortrag erzählt der Softwarearchitekt Michael Karneim von der Einführung von Test Driven Development (TDD) bei einem Pharmagroßhandelsunternehmen. Er berichtet von den Erkenntnissen, die er während dieses Projekts gewonnen hat. Er gibt einen Überblick über die Techniken, die seiner Meinung nach essentiell für die erfolgreiche Einführung sind: Gute Testframeworks, Akzeptanztests, Test-DSLs, Test-Data-Factories, Backdoors und Continuous Integration. Er hat die Erfahrung gemacht, dass deren Einsatzaufwand sich schon in der Anfangsphase eines Projekts amortisieren kann. Insbesondere spricht er von den Auswirkungen, die TDD auf die Entwicklungsgeschwindigkeit, die Softwarearchitektur und Aspekte der Softwarequalität jenseits der Korrektheit hat. Seines Erachtens kann der positive Einfluss von TDD gar nicht hoch genug bewertet werden. Dennoch ist TDD keine Silver Bullet. Der Erfolg in einem Projekt ist neben der Auswahl der richtigen Techniken insbesondere davon abhängig, dass das Team diesen Ansatz verinnerlicht hat und sein Hauptaugenmerk nicht mehr allein auf den Code, sondern zu einem wesentlichen Teil auf die Tests legt.