TDD ist für Träumer, nicht für Praktiker, oder?

Conference Day - 16. Februar
 
16:30
17:15
 
Qualität
 
Seminarraum 1.812

Test-Driven Development ist der Weg zu fehlerfreier Software. Es verkörpert das Ideal, dass jedes noch so kleine Stück Source Code getestet wird. Es bedeutet das Ende von fehlerhafter Funktionalität. Es nimmt die Angst vor Refactoring durch umfangreichen Regression-Test-Suites. Es ermöglicht eine hohe Entwicklungsgeschwindigkeit durch gute Modularisierung und stabile APIs. TDD ist der heilige Gral der Softwareindustrie. Oder?
Test-Driven Development ist die Träumerei von fehlerfreier Software. Es ist eine nette Idee für Kindergartenbeispiele wie das Game of Life, aber unbrauchbar für richtige Softwareentwicklung. Es bedeutet hohen Aufwand für eine umfangreiche Test-Suite von fraglichem Nutzen. Es bedeutet das Ende von Refactoring, weil jede Änderung die Anpassung dutzender Tests nach sich zieht. Es bremst selbst die besten Entwickler aus, weil immer mehr Zeit in den Test-Code statt in den Produktiv-Code fließt. TDD ist nicht praktikabel. Oder?
TDD ist zweifelsfrei ein Buzzword, an dem sich sprichwörtlich die Geister scheiden. Von fanatischen TDD-Jüngern bis zu kategorischen Testverweigerern findet sich so ziemlich jede Überzeugung, vorzugsweise natürlich im festen Glauben, die einzige Wahrheit für sich zu beanspruchen. Große Namen wie Uncle Bob, Kent Beck und Martin Fowler propagieren seit Jahrzehnten den Wert von TDD und trotzdem hat es sich in der Praxis noch immer nicht durchgesetzt. Wo also liegt die Wahrheit? Wenn TDD so viele Probleme löst, wo ist der Haken? Wo unterscheiden sich Theorie und Praxis?
Im ersten Teil meines Vortrags möchte ich hinter die Fronten der TDD-Diskussion blicken. Denn wenn wir TDD mit dem nüchternen Blick des Ingenieurs betrachtet, fällt ins Auge, dass TDD gar nicht eindeutig definiert ist. Man stößt auf verschiedene Denkschulen wie das sogenannte "Detroit-School", "Classic" oder "Bottom-Up" TDD und das sogenannte "London-School" oder "Top-Down" TDD. Man hört, dass selbst TDD-Erfinder Kent Beck [1], den bedingungslosen Einsatz von TDD ablehnt. Und man entdeckt TDD als ein Designwerkzeug und Mechanismus zur Selbstkontrolle der eigenen Arbeit, im Gegensatz zu einem Generator für möglichst große Test-Suites.
Im zweiten Teil meines Vortrags möchte ich im Live-Coding meinen persönlichen TDD-Kompromiss demonstrieren. Ich werde die Ebene der Kindergartenbeispiele verlassen und in Kauf nehmen, dass wir keine fertige Lösung erreichen. Vielmehr möchte ich Möglichkeiten aufzeigen, typische Probleme und Vermeidungsstrategien diskutieren und hoffentlich dem ein oder anderen Mut machen, auch im Entwickleralltag nicht vor TDD zurückzuschrecken.
TDD ist nicht praktikabel, aber kein TDD ist auch keine Lösung.
[1] Is TDD Dead? http://martinfowler.com/articles/is-tdd-dead/

Vortragsfolien: 

Sven Amann

TU Darmstadt, Deutschland

Sven Amann studierte Informatik an der TU Darmstadt und der Pontifícia Universidade Católica do Rio de Janeiro. Bereits in seinem Studium setzte er sich intensiv mit Software Engineering, agilen Methoden und Projektmanagement auseinander. Zeitgleich sammelte er praktische Erfahrung als Werkstudent bei Software AG und als selbstständiger Softwareentwickler u.A. für die GFTN e.V. und die Laborgenossenschaft Darmstadt e.G.. Seit 2013 promoviert er am Fachgebiet Softwaretechnik der TU Darmstadt zum Thema "Assistenzwerkzeuge für Softwareentwickler". Seit 2014 wird seine Arbeit vom Führungskräfteentwicklungsprogramm Software Campus gefördert. Im Rahmen seiner Initiative "Let's Developer" veröffentlicht er seit 2014 Materialien über Softwareentwicklung und Softwarecraftsmenship auf letsdeveloper.com.