Test Driven Development
Dieser Beitrag stammt aus dem Archiv. Er ist schon einige Jahre alt, manche Werkzeuge, Versionen und Links sind vielleicht nicht mehr aktuell.
Test Driven Development (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten:
- Rot – Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
- Grün – Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
- Refaktorisiere – Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.
Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich.
Kent Beck hat in Test Driven Development das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.
Hinweis: Einige Links in diesem Beitrag sind Affiliate-Links. Wenn du darüber etwas kaufst, bekomme ich eine kleine Provision. Am Preis ändert sich für dich nichts.