TDD

Was ist TDD?

TDD – steht für Test Driven Development (Test-Betriebene Entwicklung). Viele erfahrene Programmierer und Fachleute verwenden oft diesen Begriff. Sie erzählen von unglaublich stabilen und qualitativ hochwertigen Applikationen, die genau nach dieser Methode entwickelt wurden. Vor allem für unerfahrene Entwickler klingt das Ganze nach einer sehr hohen und mysteriösen Kunst, die nicht jeder beherrscht und beherrschen kann. Dabei ist es ein einfaches Konzept, den jeder in seine alltägliche Arbeit einbringen kann und auf jeden Fall einbringen sollte.

Was ist eigentlich TDD?

Nun, das lässt sich leicht mit zwei Sätzen schildern:

  1. Zuerst wird der Test geschrieben, danach die eigentliche Implementierung!
  2. Für jede Methode und Funktion der Klasse gibt es mindestens einen Test.

TDD Rhythmus

Die testbetriebene Entwicklung weist einen sich ständig wiederholenden Rhythmus auf:

  1. Das Schreiben eines Tests der durchfällt (FAIL)
  2. Implementierung der eigentlichen Klasse, Methode oder Funktion, bis der Test besteht (SUCCESS)
  3. Optimierung des Codes, durch Refaktoring: (REFACTOR)
    • bessere Namen
    • Entfernung der Duplikate
    • Verbesserung der Lesbarkeit

Grafische Darstellung:

TDD

Einzelschritte der testbetriebenen Entwicklung

FAIL

Aller Anfang ist schwer! Viele Entwickler wissen nicht womitsie starten sollten.Womit soll der Test beginnen? Welcher Test soll als erstes geschrieben werden?

Die nachfolgenden Punkte sollen eine Hilfestellung leisten:

  • Fangen sie ganz einfach an (Nullprüfung, Parameterprüfung, usw.)
  • Gehen sie vom Leichtem zum Schwierigem übergehen
  • Erst das Wichtigste, dann die Details
  • Hören sie auf innere Stimme: Erfahrung

SUCCESS

  • Schreiben sie das Einfachste, es soll nur funktionieren
  • Gehen sie mit der Implementierung nicht zu weit, der Test soll nur Grün werden
  • Test bestanden, super, sie brauchen nichts mehr (denken sie nicht an die potenziellen Möglichkeiten der Klasse, Methode oder Funktion)
  • Konzentrieren sie sich nur auf die eine konkrete Implementierung, vergessen sie aber nicht das Gesamtbild

REFACTOR

  • Code läuft, super, ist dieser aber auch lesbar?
  • Besteht Verbesserungs- oder Optimierungspotenzial
  • Befolgt die Implementierung alle OO-Regeln
  • Test erfolgreich? Sein sie so frei diesen Code zu perfektionieren
    • entfernen sie Duplikate
    • vergeben sie bessere Namen an Variablen, Funktionen oder Methoden
    • überprüfen und ändern sie die Sichtbarkeit der Variablen, Funktionen und Methoden
    • Sie dürfen Teile des Codes verschieben, entkernen und säubern
    • Starten sie den Test erneut nach jeder Änderung

Warum eigentlich nach TDD -Methode entwickeln?

  • Der gesamte Code ist getestet und überprüft (Qualitätsmerkmal)
  • Der Code ist sauber, dieser ist nur für den Durchlauf der Test geschrieben nichts Überflüssiges (schlank)
  • Der Code konzentriert sich auf eine Problem (Konkret)
  • Nach der Reorganisation ist der Code immer noch sauber und kann immer getestet werden (keine Furcht vor Veränderungen)
  • Sie können immer leicht aus dem Test in den Code springen (Problem einkreisen)

Schritt für Schritt „test-first“

  1. Denken sie drüber nach was die Klasse tun soll
  2. Schreiben sie zu der Klasse einen Test
  3. Legen sie die Klasse leer an
  4. Führen sie den ersten Test aus (FAIL)
  5. Erweitern sie den Test mit nötigen Informationen
  6. Es ist Zeit den Klassencode zu schreiben
  7. Klasse fertig?! Führen sie den Test aus, dieser sollte von Rot auf Grün umschalten (SUCCESS)
  8. Säubern Sie ihren Code, verbessern und optimieren sie ihre Klasse. Machen sie die Klasse informativer, geben sie allen Variablen, Methoden, Funktionen sprechende Namen.
  9. Starten sie den Test neu, bestanden? Sie haben Ihre Aufgabe gemeistert! Glückwunsch!

Stellen sie die Qualität Ihrer Software sicher, in dem sie immer nach der TDD-Methode entwickeln.