Fort- und Weiterbildung

Sauberer Code bedeutet testbarer Code. Um Code testbar zu machen, ist es hilfreich, die Programmierung mit Tests zu beginnen. Das ist es, worum es bei TDD immer ging.

Leider ist es schwierig, mit TDD durchgängig zu entwickeln. Ja, vielleicht wurde das Wichtigste bereits von Kent Beck in »TDD by Example« gesagt - aber was bedeutet das wirklich? TDD, wie es traditionell gelehrt wird, scheint einfach zu sein, aber am Ende ist es das eben nicht.

Dieser Workshop verfolgt daher einen anderen Ansatz für test-driven coding. Er baut auf dem traditionellen Red-Green-Refactor-Rhythmus auf, bietet aber verschiedene Möglichkeiten, mit unterschiedlichen Situationen umzugehen. Zwei weitere Gänge werden zu dem einzigen des ursprünglichen TDD hinzugefügt. Die Teilnehmer lernen, je nachdem, wie gut sie vorankommen, durch diese Gänge zu schalten.

Was die Gänge unterscheidet, ist das, was in der grünen Phase von TDD getan wird:

1. Gang: Zerlegen des Produktionscodes in kleinere Probleme, bevor Logik und weitere Tests geschrieben werden - oder »Informed TDD« von Ralf Westphal.

2. Gang: Produktionscode inline im Test - oder »TDD as if you meant it« von Keith Braithwaite.

3. Gang: Implementieren des Produktionscodes auf KISS-Basis - oder das originale TDD von Kent Beck. 

In welchem TDD-Gang die Codierung erfolgt, ist eine Frage der Klarheit: Wie gut wird das Problem verstanden? Wie gut wurde eine Lösung modelliert? Wie tief ist die Erfahrung mit den erforderlichen Technologien?

Ziel

Niedrigere Gänge sind für schwierigere Situationen geeignet. Der Workshop fügt somit zwei Gänge unter dem ursprünglichen TDD-Modus hinzu. Dies geschieht auf der Grundlage der Erkenntnis, dass die Programmierung der Produktionslogik oft zu früh gestartet und der Refactoring-Schritt allzu oft übersprungen wird. Mit dem 1. und 2. Gang wird das Refactoring weniger zur Belastung oder es wird unvermeidlich und einfach.

Außerdem: Die Teilnehmer lernen, sich nicht mit Tests in eine Ecke zu pinseln. Tests dürfen nicht zu einem Korsett werden und später die Refactoring-Bemühungen ersticken. Es wird eine klare Unterscheidung zwischen Reifetests (»Ist der Code schon korrekt?«) und Regressionstests (»Ist der Code noch korrekt?«) getroffen.

Automatisierte Tests sind zu wichtig, um eine Belastung zu sein. Es ist das Ziel des Workshops, das Testen zu einer lohnenden und angenehmen Aktivität für jeden Entwickler zu machen.