Test Driven Development ist die Technik des 21.Jahrhunderts, die meine Art Software zu entwickeln mindestens so nachhaltig geprägt hat wie die objektorientierte Programmierung (OOP) oder das Buildframework Maven.

Was bedeutet testgetriebenes Entwickeln?
Ich will hier natürlich nicht die xte Erläuterung liefern, was TDD bedeutet und wie es läuft. Andererseits kann ich nicht über die Technik des tesgetriebenen Entwickelns sprechen, ohne den Kern dieser Technik dargestellt zu haben.

Beim testgetriebenen Entwickeln geht es nicht um das Design oder den Entwurf der Anwendung, der Komponenten. Dieser muss vorher passieren. Ich komme also auch mit TDD nicht umhin, ein paar UML-Skizzen zu zeichnen, die mir vorgeben, was die Aufgabe der jeweiligen Komponenten (Klassen/Methoden) ist.

Dies soll an einem kleinen Beispiel Schritt für Schritt erläutert werden.

Aber vorneweg der Hinweis auf die 8 Gründe für TDD, für alle die, die Argumente für TDD brauchen.

Die Aufgabe sei, eine Klasse zu schreiben, die arabischen Zahlen (1,2,3,…) in römische Zeichen umwandelt, so wie hier beschrieben.

Der Entwurf ist hier denkbar einfach. Ich benötige eine Klasse Arabic2RomanConverter, mit einer public Methode String convert(int arabicNumber) throws IllegalArgumentException.
Die Methode soll für 0 bis 3000 die römischen Zeichen liefern und in allen anderen Fällen eine IllegalArgumentException werfen.

Nun kann ich mit dem Test-First Ansatz starten.

package de.mike.examples;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class Arabic2RomanConverterTest {
    
    @Test
    public void test1000() {
        Arabic2RomanConverter converter = new Arabic2RomanConverter();
        assertEquals("M", converter.convert(1000));
    }
 
}

Jeder Test gliedert sich in maximal 4 Vorgänge:

  • Test preparation
  • Test execution
  • Test assertion/verification
  • Test clean up

In meinem einfachen Fall findet die Testvorbereitung in Zeile 12 statt. Die Ausführung und Überprüfung in Zeile 13. Das Aufräumen übernimmt der Garbage Collector von Java für mich.

Da die Klasse Arabic2RomanConverter noch nicht existiert, ist der Test rot (und zwar im besten Sinne des TDD).
Rote Tests sollten so schnell wie möglich grün gemacht werden.

Der einfachste Fall, dies hier zu tun, ist die folgende Klasse;

package de.mike.examples;

public class Arabic2RomanConverter {
    
    public String convert(int arabicNumber) {
        return "M";
    }
}

Warum soll der rote Test so schnell wie möglich grün werden?
Nun dafür gibt es vielerlei Gründe. Allen voran läuft etwas nicht, was laufen sollte, und das widerstebt einem guten Software Entwickler stets.
Des Weiteren verfolge ich als Clean Code Developer immer auch das YAGNI (You ain’t gonna need it) Prinzip. Dies lehrt mich, dass die Rückgabe des konstanten Werts „M“ an dieser Stelle ausreicht, weil es noch keine weiteren Vorgaben durch Tests, und nur davon lasse ich mich treiben, gibt.
Dieses sich von den Tests treiben zu lassen, hat den Vorteil, dass ich mir bei der Implementierung NICHT mehr den Gedanken machen muss, was mein Programm zu leisten hat, sondern mich darauf konzentrieren kann, wie ich es implementiere.
Warum Generationen von Entwicklern nicht versucht haben, dies früher zu trennen, sondern immer noch mit dem Debugger im Gepäck alle Probleme auf einmal lösen wollten, ist mir, seit ich testgetrieben entwickeln kann und darf, schleierhaft.

Aber vorher kümmere ich mich um die wichtigste haltlose Bemerkung der Software Entwickler. Immer wieder höre ich in meinen Schulungen den Satz:

„Wir testen gar nicht.“ (N.N. des DEV-Teams)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.