Further Education

Worum geht´s?

Langfristig hohe Produktivität stellt sich nur ein, wenn Anforderungen stabil erfüllt werden. Eine Weiterentwicklung darf die bisherige Qualität nicht negativ beeinflussen. Veränderungen dürfen nicht zu Regressionen führen. Zu jedem Zeitpunkt sollte deshalb ein Softwareteam die Frage beantworten können, ob aktuelle Änderungen die Stabilität kompromittiert haben, ob also die Software noch korrekt ist. Gleichfalls sollte zu jedem Zeitpunkt ein Softwareteam die Frage beantworten können, ob eine aktuelle Veränderung schon den Anforderungen entspricht, so sie also »reif zur Auslieferung« ist. Reife und Regressionsfreiheit lassen sich jederzeitig, nachvollziehbar, personenunabhängig und verlässlich nur mit automatisierten Tests feststellen. Und automatisierte Tests werden verlässlich nur geschrieben, wenn das vor einer Veränderung des Produktionscodes geschieht, dessen Reife und dessen Einfluss auf die Stabilität sie überprüfen sollen. 

Die test-first Codierung ist mithin ein Herzstück fachgerechter und verantwortungsvoller Softwareentwicklung. Allerdings ist ein test-first Vorgehen nicht gleichzusetzen mit Test-Driven Development (TDD). TDD ist vielmehr nur eine Variante mit einem begrenzten Einsatzgebiet. Das hängt vom Schwierigkeitsgrad des zu lösenden Problems ab.

Das Training Test-first Codierung vermittelt deshalb nicht nur TDD, sondern verortet diesen vielbeachteten Ansatz als einen von mehreren im Rahmen eines Modells zur Beurteilung von Problemschwierigkeitsgraden. 

Inhalt

• Die Kernphasen einer systematischen Softwareentwicklung im Überblick: Analyse, Entwurf, Codierung
• Die Testmatrix: Vorgehensweisen für verschiedene Schwierigkeitsgrade
  • Triviale Probleme
  • Einfache Probleme
  • Komplizierte Probleme
  • Komplexe Probleme
  • Chaotische Probleme
• Tests als Treiber der Modularisierung
• Das Abhängige testen mit Surrogaten
• Test-first Refaktorisierung

Lernziele

• Probleme im Schwierigkeitsgrad richtig einschätzen und mit einem passenden test-first Ansatz bewältigen.
• Module als Reaktion auf die Notwendigkeit eines test-first Vorgehens natürlich wachsen lassen.
• Logik gezielt testbar machen durch eine prinzipiengeleitete Strukturierung.
• Die Testmenge begrenzen, um Selbsteinschnürungen zu vermeiden: so viel wie nötig testen, aber auch nur so wenig wie möglich.
• Ancient Code und Legacy Code nachträglich systematisch testbar(er) machen.