Test Driven Development

Beim Test Driven Development (TDD) handelt es sich um eine Methode der Softwareentwicklung, die, wie der Name sagt, den Test von Anfang an miteinbezieht.
 
Die traditionelle Softwareentwicklung schlägt vor, zuerst phasenweise Kundenanforderungen umzusetzen und am Ende unabhängig zu testen. Die Tests werden dabei entweder parallel zur Entwicklung der Software oder erst am Ende der Entwicklung erstellt. TDD kehrt diese Vorgehensweise um. Der Programmierer überlegt sich bereits vor der Programmierung, welche Anforderungen die Software erfüllen muss und welche Tests sinnvoll sind. Basierend auf den Tests erfolgt die eigentliche Programmierung schrittweise in kurzen, iterativen Zyklen. Jeder durchlaufene Zyklus optimiert die Software um weitere Eigenschaften. Dabei wird wie folgt vorgegangen:

  1. Test erstellen: Für jede neue Eigenschaft, die der Kunde an die Software stellt, wird ein neuer Test generiert. Um einen Test zu erzeugen, muss der Entwickler die Kundenanforderungen beziehungsweise Besonderheiten der Software eindeutig verstehen.
  2. Test durchführen: Beim ersten Testdurchlauf soll nicht die Programmierung überprüft werden, da bisher noch keine einzige Zeile Code geschrieben wurde. Der erste Testdurchlauf dient zur funktionalen Überprüfung der Testumgebung und stellt sicher, dass der Test an sich läuft und das erwartete Ergebnis "Fehler" liefert.
  3. Code schreiben/anpassen: Nach dem ersten Test wird der Code mit möglichst wenig Aufwand geschrieben, so dass dieser den nächsten Test einfach nur besteht. Funktionalitäten weiterer Phasen sollen nicht vorweg genommen werden. Der geschriebene Code ist im jetzigen Zustand nicht perfekt, wird aber in den nächsten Durchläufen weiter optimiert.
  4. Test durchführen: Wurde der Code geschrieben beziehungsweise angepasst, erfolgt erneut ein Testdurchlauf. Die Schritte 3 und 4 werden dabei so lange durchlaufen, bis alle Testfälle für die programmierte Einheit bestanden werden. Der Entwickler kann nun zuversichtlich sein, dass der Code alle getesteten Anforderungen erfüllt.
  5. Refaktorisierung: Im letzten Schritt wird der Code durch Refaktorisierung vereinfacht, redundanzfrei und verständlich gestaltet. Am Ende der Refaktorisierung empfiehlt es sich, einen letzten Testdurchlauf auszuführen um sicherzustellen, dass durch die Refaktorisierung keine bereits existierenden Funktionalitäten beschädigt wurden.

Die Entwicklung einer Software wird in unterschiedliche "Units" strukturiert. Jede Unit durchläuft den Lifecycle. Die Phasen drei und vier (Code schreiben/anpassen, Test durchführen) werden dabei so lange wiederholt, bis die gewünschte Funktionalität einer Unit erreicht ist, alle Fehler beseitigt wurden und dem Entwickler keine sinnvollen Tests mehr einfallen. Für jede Unit wiederholt sich der Prozess. TDD ist keine Testmethode sondern eine Softwareentwicklungsmethode.

Bewertung BQI Research

Seine Stärken zeigt TDD naturgemäß im Bereich Test (T), aber auch bei der Implementierung (IMP). Gute bis mittlere Abdeckung gibt es für das Qualitäts-Management (QM) und die Integration/Einführung (INT), während Wartung (W) und Requirements-Management (RM) nur schwach ausgeprägt sind. Keine Unterstützung erfahren die Disziplinen Betrieb (B), Projekt-Management (PM) sowie Systemdesign und technische Konzeption (SD).

  • Bekanntheitsgrad und Verbreitung liegen insgesamt im mittleren Bereich
  • Spezielle Tool-Unterstützung ist vorhanden
  • Die Methode ist nicht normiert/standardisiert, aber zertifiziert
  • Keine Lizenzierung erforderlich
  • Support ist vorhanden

zurück zur Studie