TDD demystified
Agile Softwareentwicklung und damit auch testgetriebene Entwicklung (TDD) sind in aller Munde. Zu TDD fallen oft Aussagen wie "Wir machen TDD, da wir unsere Tests im Vorfeld schreiben" oder "Wir machen TDD, wir haben ja JUnit-Tests".
Aber auch Meinungen wie "TDD, das funktioniert doch nur bei kleinen Algorithmen", "TDD lässt sich nur bei Grüne-Wiese-Projekten anwenden" oder "Unsere Anforderungen ändern sich zu häufig, um TDD anwenden zu können" sind ab und an zu hören.
Wir möchten live eine kleine Anforderung in einem bestehenden Produkt nach TDD umsetzen. Folgende Punkte werden dabei beleuchtet:
- Welche Vorteile und gegebenenfalls Nachteile entstehen durch die Implementierung nach TDD?
- Wie funktioniert TDD? Wann entsteht der Produktivcode tatsächlich?
- Wann und wie entstehen welche Tests und welchen Einfluss hat TDD darauf?
- Hat TDD Einfluss auf die innere und äußere Software Qualität?
Peter Fichtner
Peter Fichtner ist seit 1995 in der Fiducia & GAD tätig. Nach vielen Jahren als Java-Anwendungsentwickler wechselte er dort 2009 in die Architektur und greift mittlerweile auf fast zwei Jahrzehnte Erfahrung als Architekt, Designer und Entwickler für verschiedene Themen im Java-Umfeld zurück. Aktuell fokussiert er die Themen Test-Driven-Development (TDD), Continuous Integration (CI), Clean Code (CC) sowie agile Entwicklungsmethoden. In seiner Rolle als Coach für agiles Softwareengineering (ASE) unterstützt Peter Fichtner seit drei Jahren agile und nicht-agile Teams in der Fiducia & GAD IT AG mit Schulungen und Coachings.
Tilmann Glaser
Tilmann Glaser arbeitet seit 2011 für die it-economics GmbH. Als iSAQB zertifizierter Software Architekt betreut er Entwicklungsprojekte und unterstützt Teams als Coach für agile Softwareengineering-Methoden (ASE). An der Dualen Hochschule bringt er Studenten Java-Entwicklung und neue Konzepte der IT näher. Seine Kernthemen sind agile Transition, Architektur in agilen und klassischen Umfeldern, Clean Code, Test-Driven Development (TDD) und Project Recovery.