Test Driven Development

All code is guilty until proven innocent

von Klemens Loschy

Flexibel auf geänderte (Business-)Anforderungen reagieren zu können, die Forderung nach raschem Time-to-market zu erfüllen und trotzdem im Umgang mit Menschen respektvoll zu sein sowie Spaß an den Erfolgen des Teams haben zu können! So oder so ähnlich kann man agile Entwicklung zusammenfassen.

Wichtig bei all dem ist die Identifikation des gesamten Teams mit der geteilten Aufgabe der Qualitätssicherung („collective quality ownership“). Eine der mittlerweile immer interessanter werdenden Standard-Methoden, die hierbei zum Einsatz kommen, ist Test Driven Development, kurz TDD. Der Fokus der Methode: Qualität! Bei diesem testgetriebenen Prozess erstellt der Entwickler die Tests bevor die dazugehörende Business Logik erstellt wird - nicht erst danach oder, wie oft in der Praxis, nie.

TDD in der Praxis: „Red“ - „Green“ - „Refactor“

TDD Triangle

Test Driven Development wird oft zu Unrecht als „unnötiger zusätzlicher Aufwand“, sowohl bei Entwicklern als auch im Management, eingeschätzt. TDD zwingt den Entwickler vor der eigentlichen Umsetzung der Business Logik die zugehörigen Unit Tests zu schreiben. Es darf keine Business Logik implementiert werden, ohne zuvor einen fehlschlagenden Unit Test zu schreiben. Zusätzlich ist eine fixe Verbesserungsphase, so genanntes „Refactoring“ eingeplant, die für qualitativ hochwertige Ergebnisse sorgen soll.

Diese drei Phasen der Entwicklung – Unit Test schreiben, Business Logik umsetzen, Code verbessern – werden iterativ bis zur fertigen Lösung wiederholt. In sogenannten „Baby Steps“ wird nach und nach die Business Logik, bis zum fertigen Ergebnis, erweitert. Dies führt auf den ersten Blick zu mehr Aufwand, aber auch nur aus dem Grund, da in Vergangenheit zu wenig Aufmerksamkeit auf Unit Tests im Allgemeinen gelegt wurde. Die durch diesen Prozess entstehenden Testfälle können Fehler frühest möglich aufzeigen, die sonst erst im nachgelagerten Test oder sogar erst beim Kunden identifiziert worden wären.

Zusätzlich verbringt der Entwickler deutlich weniger Zeit im Debug Modus und kann sich so produktiver um die eigentliche Business Logik kümmern. Der so entwickelte Code hat auch den Vorteil, dass er von Anfang an testbar ist und nicht im Nachhinein für Unit Tests geändert werden muss. Aber TDD geht noch viel weiter als einfach nur die Testfälle vor der Business Logik zu schreiben: TDD ist eine Methode, die den Fokus auf qualitativ hochwertige Ergebnisse legt! Naming, Deduplication und ein gutes Design sind nur einige Punkte, die bei TDD großgeschrieben werden. Das Ergebnis ist lesbarer, wartbarer und einfach erweiterbarer bzw. änderbarer Code.

Die Vorteile von TDD

Ein wesentlicher Vorteil von Test Driven Development liegt ganz eindeutig auf der Hand: Durch den Einsatz von TDD kann eine theoretische Code Coverage der Business Logik von 100% erreicht werden. Diese Testfälle stellen die Grundqualität der entwickelten Software sicher. Zusätzlich wird mit dem Fokus auf Naming und Design ein auf lange Sicht lesbarer und wartbarer Code erstellt. Die Entwickler können durch das dicht gewebte Sicherheitsnetz der Unit Tests ohne Gefahr die Umsetzung großer Teile der Business Logik bei Bedarf ändern, denn: Die Anforderungen an die Business Logik sind in den Unit Tests persistiert und die korrekte Umsetzung kann laufend sichergestellt werden.

Ein weiterer und nicht unwesentlicher Vorteil wird durch TDD erreicht: die Entwickler sollen wieder zufrieden und stolz auf ihr Machwerk blicken können. Software Craftsmanship wird großgeschrieben, es soll allgemein ein Umdenken weg von „Programmiermaschinen“ stattfinden. Und zufriedene Arbeiter leisten doch zumeist auch gute Arbeit.

Das Prinzip von TDD

1. Erstellung des Testfalls

2. Erstellung der Logik

3. Überarbeitung der Logik

Die Vorgehensweise bei Test Driven Development mag auf den ersten Blick verwirrend oder wie Zeitverschwendung wirken, dafür die erstellten Testfälle noch keine Logik existiert, die überprüft werden kann. Jedoch ist diese Vorgehensweise, wenn sie genauer betrachtet wird, hervorragend dafür geeignet, um von Beginn an qualitativ hochwertige Software zu entwickeln. Folgende drei Phasen werden nacheinander abgearbeitet und bis zur Fertigstellung der Business Logik iterativ durchgeführt:

  1. Erstellung des Testfalls:
    Die Erstellung eines Testfalls noch bevor überhaupt der eigentliche Code geschrieben wird dient zur Überprüfung des Fortschrittes sowie der Korrektheit des Codes bei der Entwicklung der Logik. Ein Testfall, der aufgrund von fehlendem Code als „failed“ bzw. „red“ markiert wird, soll nach der Implementierung der Logik (in Phase 2) und erneuter Durchführung des Testfalls als Ergebnis „passed“ bzw. „green“ besitzen. Ein neuer roter Testfall für den Entwickler bedeutet: Es kann wieder Business Logik entwickelt werden!
  2. Erstellung der Logik:
    Wenn der entsprechende Testfall erstellt wurde, kann mit der Implementierung der Business Logik begonnen werden. Jedoch sollte nur so viel Code geschrieben werden, wie benötigt wird, damit der Test fehlerfrei durchgeführt werden kann. Im Vergleich zur bisherigen Vorgehensweise der Softwareentwicklung wird bei TDD die einfachste Implementierung zur Lösung des Problems gewählt und erst in der Refactoring-Phase überarbeitet. Dies garantiert, dass der Aufwand und die Komplexität während der Entwicklungsphase so gering wie möglich gehalten werden und sich der Entwickler zuerst mit der eigentlichen Problemlösung beschäftigen kann.
    Das Prinzip ist anfangs ungewohnt, doch wird damit ganz gezielt dem verbreiteten „Over Engineering“ vorgebeugt. Sollten während der Erstellung oder Erweiterung des Codes Fehler entstehen, können diese, dank der zuvor erstellten Testfälle, rasch gefunden und behoben werden. Am Ende von Phase 2 können alle Testfälle fehlerfrei durchgeführt werden. „Green“ meldet den Abschluss dieser Phase und leitet den Übergang zu Phase 3 ein.
  3. Überarbeitung der Logik:
    Die Refactoring-Phase wird erst dann durchgeführt, wenn die Phasen 1 und 2 komplett abgeschlossen sind. Das heißt, die einfachste Business Logik wurde implementiert, um den zuvor geschriebenen Testfall fehlerfrei durchführen zu können. Nun kann gefahrlos die Business Logik überarbeitet werden – das „Fallnetz“ stellt sicher, dass keine Änderung das Verhalten der Business Logik negativ beeinflusst. Das Refactoring der Business Logik kann mehrere Schritte, wie beispielsweise die Umbenennung von Variablen oder das Extrahieren von Teilen der Logik in eigene Methoden (um Duplication zu verringern), beinhalten.
    Das Ergebnis des Refactoring sollte eine Business Logik sein, welche durch aussagekräftige Bezeichnungen für Variablen und Methoden leicht zu lesen und durch Eliminierung von redundantem Code leicht zu warten ist. Nicht zu vergessen: Auch die Unit Tests sind wichtiger Bestandteil der Codebasis und alle Qualitätsanforderungen an die Business Logik gelten auch für die Unit Tests.
    In der Refactoring-Phase sollte daher auch der Test Code stetig verbessert werden. In der Refactoring-Phase gilt es jedoch Folgendes zu beachten: Streng verboten ist es, die Business Logik zu erweitern – das ist nur erlaubt, wenn ein zuvor geschriebener „roter“ Testfall existiert. Am Ende einer kompletten Iteration ist durch diese drei Phasen ein qualitativ hochwertiger Code mit einer hohen Wartbarkeit entstanden, welcher durch die Testfälle beliebig oft erneut getestet werden kann. Im Hinblick auf die Möglichkeit des Regressionstests ist die erneute Durchführung der Testfälle wichtig, da eine undurchdachte Änderung der Logik in einer späteren Iterationen bereits vorhandene und funktionierende Business Logik wieder zerstören kann.

Test Driven Development (TDD):

TDD ist eine Methode in der Softwareentwicklung mit dem Ziel, einen qualitätsgesicherten Code zu schreiben. Der Entwickler erstellt die Tests selbst bevor er die Komponenten programmiert. Diese Methode besteht aus den drei Phasen „Red“ - „Green“ - „Refactor“.

Autor
SEQIS Autor Klemens Loschy

Klemens Loschy

Principal Consultant, Teamlead
IT Analyse, Softwaretest, Projektmanagement

Newsletter

Um neue Beiträge per E-Mail zu erhalten, hier die E-Mail-Adresse eingeben.

Unsere Autoren

Informieren Sie sich über unsere Autoren und erfahren Sie mehr über unsere Spezialisten und ihre Fachbereiche:

Zu den Autoren

Sie haben eine Frage?

Zurück

Zum Seitenanfang navigieren