TDD 2.0 – Teil 2 | TDD as if you meant it (TDDaiymi)

“TDD ist kein Zauberstab, der aus dem Nichts wohlstrukturierten Code herstellt.” – Ralf Westphal [1]

TDD 2.0 – Teil 1 | Problemanalyse, Lösungsfindung, Implementierung

Die Refactoring-Phase in TDD dient dazu Code zu strukturieren. Es gibt allerdings keine generellen Rezepte nach welchen Kriterien man verbessertes Design als Entwickler erzeugen kann. Code Smells, wie z.B.: Duplikation, sind zwar gute Ansatzpunkte, allerdings führt die Bereinigungen dieser in TDD 1.0 nicht automatisch zu guter Struktur (= Aspekte meiner Lösung für das vorhandene Problem werden durch Refactoring nicht automatisch im Code abgebildet).

Ralf Westphal beschreibt in einer vierteiligen dotnetpro-Artikelserie, wie seiner Meinung nach das neue TDD, also TDD 2.0,auszusehen hat. Den ersten Teil habe ich bereits hier zusammengefasst. Darin ging es um die ersten beiden (neuen) Phasen: Problemanalyse und Lösungsfindung.

In diesem Post fasse ich den zweiten Teil [1] der Artikelserie von Ralf zusammen: die Implementierungsphase. Ralfs Kritik von TDD 1.0 ist das Refaktorisieren, das nicht durch die Methode selbst erzwungen wird. Dadurch wird diese Phase willkürlich von Entwicklern eingesetzt bzw. es wird komplett darauf verzichtet. Struktur kann, muss allerdings nicht, dabei entstehen. Genau das ändert sich bei TDD 2.0 in der Implementierungsphase durch den Einsatz von TDD as if you meant it.

Die Regeln von TDDaiymi sind einfach: Produktionscode wird immer nur in die Test-methode geschrieben. Fehler müssen zuerst in der Testmethode reproduziert und behoben werden. Dann wird in den Testmethoden nach Wiederholungsmustern gesucht, die Anzeichen zur Refaktorisierung darstellen.

Produktionscode nur in Testmethoden? Ja. Laut Ralf treten dabei folgende Effekte auf:

“Erstens konzentriere ich mich bei jedem Testfall nur darauf, genau diesen Testfall grün zu bekommen. Die Fokussierung ist viel größer. Ich muss keine Kompromisse bei der Lösung eingehen. Das bedeutet auch, ich bewege mich tastend fort. … Und zweitens entstehen viel häufiger (Wiederholungs-)Muster. Die sind Leitsterne für die Refaktorisierung.” [1]

Keine Kompromisse?

Da man bei TDDaiymi die Behebung eines Fehlers immer in der Testmethode selbst programmiert, läuft man nicht Gefahr,  andere Tests kaputt zu machen. Das sieht bei TDD 1.0 anders aus. Die Regeln besagen: Bereits erzeugte Tests, die einmal auf Grün waren, dürfen nicht mehr Rot werden. Deshalb muss man sich bei jedem neuen Test plus Implementierung darauf konzentrieren, dass die neue Lösung ebenfalls alte Tests berücksichtigt und nicht zerstört. Das ist in TDD 2.0 nicht mehr der Fall, denn Tests plus deren Implementierung sind unabhängig von anderen Tests. Genial.

In [1] implementiert Ralf zuerst mittels TDD 1.0 und danach mittels TDD 2.0 die Kata “WordWrap”. Bei letzterer Vorgehensweise wird allerdings nur von der dritten Phase, Implementierung mittels TDDaiymi, Gebrauch gemacht. Zur Erinnerung noch einmal die aktualisierte Version von TDD:

image

Ganz bewusst wurde auf die beiden vorhergehenden Phasen verzichtet, da TDDaiymi der Schwerpunkt des Artikels war. Ralf ergänzt, dass die entstandene Struktur bereits in der Solve-Phase hätte entdeckt werden können.

Kritik TDD 1.0

Trotz disziplinierter Anwendung von TDD 1.0 führt dies nicht im Entferntesten zu Code, der leicht verständlich ist. Unter [3] findet man sowohl Tests als auch Produktionscode der Implementierung. Folgendes Code-Snippet zeigt nur den Produktionscode aus [3]. Leider wurde ausschließlich die komplette Implementierung eingecheckt, sodass man in der Git-History die einzelnen Schritte nicht erkennen kann.

Besser mit TDD 2.0

Folgendes Code-Snippet zeigt die Lösung aus [4], die mittels TDDaiymi erzeugt wurde.

Auffällig bei dieser Implementierung ist die domänenspezifische Trennung unter- schiedlicher Aspekte. Man kann anhand des Codes genau erkennen wie die Lösung funktioniert.

In [1] wird jeder Schritt von Rot auf Grün ganz genau von Ralf erklärt. In einer tabellenartigen Darstellung befindet sich auf der linken Seite immer der Test und auf der rechten Seite die Implementierung (bei TDDaiymi erneut der Test + Produktionscode im Test). Fantastisch.

Trotzdem fiel es mir nicht besonders leicht, die einzelnen Refaktorisierungen von Ralf nachzuvollziehen. Das lag vielleicht daran, dass ich mich schon vor einiger Zeit einmal an TDDaiymi versucht habe und daher eine gewisse Vorstellung darüber hatte, wie diese Methode anzuwenden ist. Da es jedoch kaum Literatur dazu gibt, war es sehr aufschlussreich zu sehen, wie Ralf dabei vorgeht. Noch genialer wäre ein Screencast, bei dem man Ralf bei seinem Vorgehen beobachten könnte. Und siehe da Smiley :

Zwar ist die Lösung in diesem Video nicht 1:1 dieselbe wie in dem dotnetpro Artikel [1], aber es hat mir auf jeden Fall unglaublich geholfen. Nachdem ich dann selbst mehrmals WordWrap mittels TDDaiymi übte, war es mir endlich möglich, folgende Aussage von Ralf nachzuvollziehen:

“Bei TDD 2.0 hingegen gibt es zunächst gar keinen Produktionscode. Da gibt es nur Tests – bis sich ein Muster herausschält. Man ist von vornherein also im Mustererkennungsmodus für die Refaktorisierung. Weil es eine Implementierungsrichtlinie für Grün gibt – schreibe Code zunächst in der Testmethode –, wird man quasi in die Refaktorisierung gezwungen.” [1]

Ich behaupte, dass man dieses Gefühl des Mustererkennungsmodus nur verstehen kann, wenn man TDDaiymi selbst mehrmals ausprobiert hat. Man ist ständig auf der Suche nach Wiederholungen, die auf neue Aspekte hindeuten könnten.

Gelerntes

Folgende Punkte aus [2] hat Ralf unter “Was ich gelernt habe” zusammengefasst:

– Refaktorisierung ist nicht mehr optional, sondern muss vorgenommen werden.
– Dopplungen in Testmethoden sorgen ganz natürlich dafür, dass Aspekte in Lösungsmethoden verpackt werden (DRY).
– Weitere Methoden entstehen nur bei Sensibilität für SRP.
– Es ist wirklich wichtig, Lösungen zuerst in der Testmethode zu implementieren. Nur so werden Aspekte sichtbar, die sonst in Lösungsmethoden untergehen würden.

Ich finde TDDaiymi weiterhin nicht unbedingt einfach. Das Video von Ralf plus der dotnetpro Artikel [1] helfen jedoch ungemein. Ralfs Erkenntnisse stimmen mit meinen überein.

Offene Fragen

Einige Fragen stellen sich mir jedoch weiterhin: Wie sieht TDD 2.0 in realen Anwendungen aus? Kommt TDDaiymi für die komplette Applikation zur Anwendung oder nur für Teilaspekte? Ist TDDaiymi nur für die Erforschung innerer Strukturen von Klassen?

Aussichten

Im nächsten Teil hoffe ich einige dieser Fragen beantworten zu können. Außerdem beschreibt Ralf zum einen was man eigentlich unter Design versteht, zum anderen wird anhand der BowlingGame Kata der komplette TDD 2.0 Zyklus vorgeführt.

Referenzen

[1] dotnetpro Artikel: Ab ins Grüne von Ralf Westphal http://bit.ly/1i79VMi
[2] XP Days 2012 Slides zu TDDaiymi von Ralf Westphal: http://bit.ly/1ln74kQ
[3] WordWrap mittels TDD 1.0 von Ralf Westphal: http://bit.ly/1bIxnd3
[4] WordWrap mittels TDD 2.0 von Ralf Westphal: http://bit.ly/19K8408

Weitere Referenzen aus [1]:

Robert C. Martin, The Craftsman 62 – The Dark path http://bit.ly/1kDOVS8
Robert C. Martin, Uncle Bob’s Blog, The Transformation Priority Premise (Leider offline)
Code Cop, Word Wrap Kata Variants, http://bit.ly/1j8OUDW
Keith Braithwaite, TDD as if you meant it http://bit.ly/1a9JhCZ
Keith Braithwaite, TDD as if you meant it (Video) http://bit.ly/K7kbc3
Gojko Adzic, Thought-provoking TDD exercise at the Software Crapftsmanship conference http://bit.ly/1iiTK10
Gojko Adzic, TDD as if you meant it – revisited http://bit.ly/1c8BYoX

Über sageniuz

https://about.me/ClausPolanka
Dieser Beitrag wurde unter Refactoring, Software Craftsmanship, TDD abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s