Test Driven Development (TDD) ist ein iterativer Prozess, bei dem zuerst Tests für eine Funktionalität geschrieben werden, bevor die Implementierung erfolgt. Dieser Ansatz fördert Qualität und Wartbarkeit des Codes und hilft, Bugs frühzeitig zu identifizieren.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Testgetriebene Entwicklung schreibt zunächst einen automatisierten Test für ein gewünschtes Verhalten, implementiert dann die kleinste passende Lösung und verbessert anschließend den Code.
TDD wurde in der Extreme-Programming-Bewegung der 1990er-Jahre, besonders durch Kent Beck, als kurze Red-Green-Refactor-Schleife popularisiert. Der Ansatz verbindet die ältere Idee automatisierter Tests mit kleinschrittigem Entwurf.
Der Test formuliert zuerst einen beobachtbaren Vertrag: Rot zeigt die fehlende Fähigkeit, Grün bestätigt die kleinste Lösung, Refactor verbessert die Struktur bei gleichbleibendem Verhalten. Der Test ist dabei ein Entwurfswerkzeug.
Rot-Grün-Refactor
Verhalten
Rückmeldung
TDD macht gewünschtes Verhalten früh prüfbar und unterstützt kleine, rückwärtsverträgliche Änderungen. Es garantiert keine guten Anforderungen oder Systemtests; unpassende Tests können falsche Sicherheit erzeugen.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.