WikiDer > Testgetriebene Entwicklung

Test-driven development

Testgetriebene Entwicklung (TDD) ist ein Softwareentwicklungsmethode wo zuerst Tests geschrieben werden und erst dann die Code.[1] Der Name testgetriebene Entwicklung kommt von Kent Beck, der diese Technik 2002 zu Papier gebracht und dadurch bekannter gemacht hat. Es fällt unter die Agile Software Entwicklung.

Entwicklungszyklus

Der folgende Entwicklungszyklus basiert auf dem Buch Testgetriebene Entwicklung am Beispiel[2] von Kent Beck. Dieses Zyklus kann so oft wie nötig wiederholt werden, um Code um es voll funktionsfähig zu machen Anforderungen.

  1. Test erstellen: Bei der testgetriebenen Entwicklung erstellt der Programmierer zunächst einen Test basierend auf einer Anforderung und schreibt erst dann den Code.
  2. Führen Sie alle Tests aus und prüfen Sie, ob der neue Test fehlschlägt: Grundsätzlich sollte dieser Test zunächst fehlschlagen, da der Code, für den dieser Test gilt, noch nicht existiert. Das Scheitern des neuen Tests ist wichtig, um zu überprüfen, ob der Test effektiv ist (enthält keine Fehler und ist daher z. B. immer erfolgreich).
  3. Code schreiben: In diesem Schritt wird der eigentliche Code geschrieben, damit der soeben erstellte Test bestanden wird. Dieser Code darf nur sein Funktionalität zum Bestehen der Prüfung notwendig. Der Code muss nicht perfekt geschrieben sein, solange er funktioniert. In einem späteren Schritt wird der Code gemäß dem Standard neu geschrieben.
  4. Führen Sie Tests durch und prüfen Sie, ob sie bestehen: In diesem Schritt werden alle Tests erneut ausgeführt und geprüft, ob alle Tests erfolgreich sind. Wenn ja, ist dies ein guter Ausgangspunkt für den nächsten Schritt.
  5. Code umschreiben: In diesem Schritt wird der Code bereinigt und gemäß dem Standard neu geschrieben. Außerdem wird jeglicher doppelter Code, der benötigt wird, um die gegenseitige Abhängigkeit der Komponenten zu minimieren, entfernt.

Leistungen

  • Testgetriebene Entwicklung wird aus der Perspektive der Benutzer. Das Testfälle für die der Code geschrieben wird, basieren auf den Anforderungen, die aus Sicht des Benutzers erstellt wurden. Probleme mit der Benutzerfreundlichkeit der Schnittstelle können so früher zum günstigsten Zeitpunkt gefunden und korrigiert werden.[3]
  • Besonderes Augenmerk wird auf die Anforderungen gelegt, da die Tests darauf aufbauen. Dadurch werden zusätzliche, vielleicht überflüssige Funktionalitäten nicht implementiert, so dass sich der Umfang des Programmcodes in Grenzen hält.
  • Da der gesamte Code von Grund auf getestet wird, schafft dies mehr Vertrauen in das Entwicklungsteam und den Kunden.
  • Trotz des zusätzlichen Codes, der zum Schreiben der Tests benötigt wird, wird die Entwicklungszeit dennoch verkürzt, da Fehler in einem sehr frühen Stadium gefunden werden.
  • Da alle Teile des Codes getrennt voneinander getestet werden, ist die Abhängigkeit kleiner und damit weniger komplex.

Nachteile

  • Bei dieser Methode schreibt der Programmierer sowohl die Tests als auch den Code für die Anwendung. Wenn der Programmierer etwas übersieht, wird es daher sowohl im Test als auch im Code übersehen.
  • Wenn viele Tests erfolgreich sind, kann dies den Eindruck erwecken, dass die Anwendung vollständig getestet wurde. Ein Fallstrick ist, dass ein Integrations- und Systemtest kaum oder gar nicht durchgeführt wird.

Anwendung

Diese Methode lässt sich gut kombinieren mit extremes Programmieren (XP), da auch XP kurze Entwicklungszyklen mit kontinuierlichem Testen der Software nutzt.