Bei der testgetriebenen Entwicklung (Test-Driven Development, TDD) werden Tests dazu benutzt, um die Softwareentwicklung zu steuern.
Grundsätzlich werden die Tests vor dem eigentlichen ProgrammCode geschriebenDer Ablauf dieser Programmierung ist immer gleich:
Ein Test wird geschrieben, der zunächst fehlschlägt. (Es gibt noch gar keinen testbaren Code für den Test)
Code wird geschrieben, dass der Test erfolgreich durchläuft.
TestCode und Produktivcode werden refaktorisiert.
Tests, die erfolgreich durchlaufen, werden durch einen grünen, nicht erfolgreiche durch einen roten Balken dargestellt. Man spricht daher vom "Red-Green-Refactor"-Zyklus.
Das die Tests noch vor den eigentlichen Komponenten geschrieben werden, die getestet werden sollen, ist das Merkmal für TDD. Dies wird als Test-First bezeichnet und darum ist TDD keine Test-, sondern eigentlich, wenn man es genauer betrachtet, eine Designstrategie.
Wird ein Test zuerst geschrieben, so wird die Schnittstelle der zu testenden Komponente bereits benutzt, bevor sie überhaupt existiert. Der Entwickler bekommt rasch Feedback, ob das angedachte Design überhaupt verwendet werden kann.
Die Implementierung des produktiven Codes erfolgt erst, wenn ein Test vorliegt, der dies verlangt. Es soll immer nur genau so viel Code geschrieben werden, dass der Test erfolgreich durchläuft. Es darf also nicht zu viel Produktivcode für einen Test geschrieben werden. Es würden dann nicht getestete Stellen entstehen, die später Probleme bereiten können.
Beim Refactoring werden der Test- sowie Produktivcode aufgeräumt. Ziel hierbei ist es, die Software einfach und verständlich zu gestalten.
Prinzipien, die TDD vereint, sind die kontinuierliche Designverbesserung, einfaches Design und Test-First.
