Testgetriebene Entwicklung nach der Münchner Schule

Testgetriebene Entwicklung (Test Driven Development, TDD) ist eine beliebte und nützliche Methodik. Richtig angewendet reduziert TDD die Fehlerdichte signifikant, ohne dabei Produktivitätsverluste in Kauf nehmen zu müssen. Vor allem hilft TDD, Softwaredesign zu verbessern.

Geschichte und Ausprägungen

Der Wiederentdecker von TDD Kent Beck verrät, dass er die Idee aus einem äußerst alten Programmierhandbuch übernommen hat. Tatsächlich lassen sich die Ursprünge bis hin zu John von Neumann ins Jahr 1957 zurückverfolgen, der TDD seinerzeit mit vorgestanzten Lochstreifen betrieb.

In vielen Projekten der 60er und 70er Jahre unter anderem bei der NASA finden sich Hinweise auf frühes TDD. Leider ist das Wissen über die Technik anschließend für längere Zeit in Vergessenheit geraten oder war nur noch wenigen Eingeweihten bekannt. Erst 1989 entwickelte Kent Beck sUnit für Smalltalk und später jUnit für Java und begründete damit das moderne TDD. Über 60 Jahre TDD sind Grund genug zu fragen, wie sich die Methodik seither weiterentwickelt hat.

Vielfältige Stile

Wer TDD-Entwicklerinnen und -Entwicklern über die Schulter schaut, erkennt schnell unterschiedliche Methoden. Im Laufe der Jahre sind verschiedene Stile entstanden, die die Szene gerne als TDD-Schulen bezeichnet. Tatsächlich lassen sich Parallelen zur Kampfkunst feststellen – dort tragen Schulen oft den Namen ihres regionalen Ursprungs. Dasselbe gilt für das Test-driven Development.

Aktuell lassen sich mindestens sechs Schulen identifizieren:

• Chicago/Detroit Schule von Kent Beck
• Londoner Schule von Nat Price & Steve Freeman
• Münchner Schule von David Völkel
• St. Pauli Schule von Steven Collins
• Hamburger Schule von Ralf Westphal
• TDD as if you Meant It von Keith Braithwaite

Daneben gibt es weitere TDD-Stile, aber die sechs stechen hervor, weil sie mit einem eigenen Namen benannt und ihre jeweiligen Konzepte gut dokumentiert sind. Chicago und London sind die beiden ältesten, für die viel Literatur zur Verfügung steht. Die anderen Schulen sind bisher unterrepräsentiert. Das ist ein Grund, in diesem Artikel die Münchner Schule detaillierter vorzustellen.

Motivation für die Gründung

David Völkel hat die Münchner Schule vor allem als Reaktion auf die Londoner Schule ins Leben gerufen. Letztere verzeichnet als eine der herausragenden Eigenschaften das sogenannte Outside-in-Vorgehen: Ein Akzeptanztest bildet auf hoher Ebene eine geforderte Anforderung ab. Um ihn zum Bestehen (grün) zu bringen, ist einiges an Aufwand nötig. Dazu dient weitere testgetriebene Entwicklung von der äußeren API bis in den Kern des Produktionscodes. Der erste Akzeptanztest bleibt derweil rot.

Erst nach dem Ende des inneren TDD-Zyklus färbt sich der äußere Akzeptanztest grün, und damit beginnt ein neuer Zyklus. Emily Bache beschreibt dieses Vorgehen als Double-Loop ATDD (Acceptance Test Driven Development).

Die konkrete Anforderung steht auch bei dem inneren Loop stets im Vordergrund. Das Vorgehen erzeugt eine Layer-Struktur, bei der jede neue Schicht die Anforderung der darüber liegenden erfüllt. Das verhindert nach dem YAGNI-Prinzip ("You Aren't Gonna Need It"), dass überflüssiger Code entsteht. Jedes Stück Produktionscode ist erwiesenermaßen am Ende für das Projekt erforderlich. Damit die Tests nicht über die ganze Zeit des inneren Loops rot bleiben, erfolgt die Verifikation mit Mocks oder Spies sozusagen durch die Hintertür – die sogenannte Backdoor-Verification.

pushSpy = jest.spyOn(Array.prototype.push);
deck.addCardOnTop("9-Hearts");
expect(pushSpy).toHaveBeenCalledWith("9-Hearts");

Die Beispiele in diesem Artikel sind in JavaScript verfasst, aber die Programmiersprache spielt für die TDD-Schulen und die damit verbundenen Konzepte keine Rolle.

Im Code legt die Methode addCardOnTop die Karte "9-Hearts" auf ein Kartendeck. Statt den geänderten State ("9-Hearts" oben liegend, eine Karte mehr als vorher im Deck) zu überprüfen, stellt Backdoor-Verification sicher, dass der Produktionscode die darunter liegende Methode push des Array-Objektes mit dem richtigen Parameter "9-Hearts" aufgerufen hat. Auf die Weise lässt sich ein Layer des Produktionscodes schreiben, ohne dass der darunterliegende vorhanden sein muss.

Auf der Plus-Seite der Londoner Schule steht also die Beweisbarkeit, dass der Produktionscode erforderlich ist. Somit schreibt niemand überflüssigen Code. Ein weiterer Vorteil ist das konsequente Vorgehen: Es ist normalerweise deutlich, welcher Schritt als nächstes ansteht. Ein freies Experimentieren wie bei der Chicago Schule ist nicht nötig.

Auf der anderen Seite ist der häufige Einsatz von Mocks ein Nachteil. Sie sind oft schwer zu lesen und führen zu einer starken Verzahnung von Test- und Produktionscode. Als Folge ergeben sich fragile Tests.

Diese Schwächen auszugleichen war die Motivation bei der Gründung der Münchner Schule. Sie versucht, die Frage zu beantworten, ob sich das Outside-In-Vorgehen mit all seinen positiven Eigenschaften beibehalten lässt, ohne auf Mocks zurückgreifen zu müssen.

Auf den Schultern von Riesen

Die Münchner Schule ist kein völlig neues Konzept, sondern greift bestehende Muster und Konzepte auf, die länger bekannt sind und die sie zu einem kohärenten Vorgehen zusammenschnürt. Folgende Konzepte dienen als Grundlage:

• Fake-It von Kent Beck und Llewelyn Falco,
• Preparatory Refactoring von Kent Beck,
• Double Loop ATDD von Emily Bache und
• Integration Operation Segregation Principle von Ralf Westphal.

Dazu gesellen sich zwei weitere, die Völkel entwickelt hat, um sein Vorgehen zu ermöglichen: Backward Calculation und Intermediate Test.