Coding Dojos erfreuen sich großer Beliebtheit. Kein Wunder, kann man sich dank ihnen doch endlich mal ungezwungen mit dem wirklichen Handwerk unserer Zunft auseinander setzen: Dem Produzieren von Code.

Obwohl es nun schon eine ganze Reihe von Katas (Aufgaben) gibt, juckte es mir doch seit geraumer Zeit in den Fingern wenn ich an eine Aufgabenstellung dachte, die aus meiner Sicht bisher noch keiner verfasst hatte.

Wohl ausgelöst durch den aktuellen Jackpot, haben ich mir nun ein Herz gefasst und einfach mal die deutschen Lottoregeln im Stil einer Kata betrachtet. Wie diese aussehen, kann man entweder bei Wikipedia nachlesen oder folgend.

Die Aufgabenstellung

The aim of this kata is to calculate winning classes in the German lottery „6 aus 49“. This is a typical lottery were 6 numbers out of 49 are drawn. Additionally two extra balls are drawn; one for the so called Additional Number and one for the Super Number.

The Super Number is a ball with a digit between 0 and 9, which is needed to get the jackpot if all 6 regular numbers are hit. The Additional Number is drawn after the first 6 and will thus also be between 1 and 49. It gives the player another chance of a matching number, resulting in a higher prize.

Wins are classified as follows:
Class 8: 3 out of 6
Class 7: 3 out of 6 + Additional Number
Class 6: 4 out of 6
Class 5: 4 out of 6 + Additional Number
Class 4: 5 out of 6
Class 3: 5 out of 6 + Additional Number
Class 2: 6 out of 6
Class 1: 6 out of 6 + Super Number

This example should clarify how the the additional number works:
—————————-
Played ticket:
Numbers 1 2 3 4 5 49
SN 8

Drawn ticket:
Numbers 1 2 3 7 8 9
AN 49
SN 0

The result should be „class 7“ because the regular numbers 1, 2 and 3 were hit and also the Additional Number 49 matches.

Retrospektive

Um Lust darauf zu machen die Aufgabe mit offenen Augen selbst zu probieren, möchte ich an der Stelle gleich mal meine Beobachtungen schildern.

1. Das Problem ist recht einfach.
Hat man die Anfangshürde genommen, in der Infrastrukturklassen wie ein Ticket usw. definiert werden, wird die Logik sehr schnell umgesetzt. Für die ersten Tests braucht man dann zunächst auch nicht viel, da sie meist mit nur kleinen Anpassungen per Copy&Paste erstellt werden können.

Im Gegensatz zu anderen Katas fehlte mir zunächst ein wenig der Twist in der Aufgabenstellung. Ja es begann zwischenzeitlich sogar langweilig zu werden! Bei FizzBuzz kennzeichnet diesen Twist zum Beispiel der dritte Teil der Aufgabe, bei dem man für Zahlen die durch 3 und 5 teilbar sind eben FizzBuzz ausgeben muss. Gleiches fand ich zum Beispiel auch bei der Harry Potter oder der Bowling Kata.

Durch diese Twists ist man gezwungen den Code und nicht selten auch die Tests zu refaktorisieren, was wiederum die Stärke von Unit-Tests und TDD zeigt. Denn durch die ständige Prüfung der Tests gegen die eigentliche Logik und umgekehrt, kann der Code verändert werden ohne dauerhafte Schäden an der Funktionalität zu hinterlassen.

2. Man produziert zunächst sehr viele gleichartige Tests
Obwohl ich pro Test eigentlich nur das Assert und eine einzige Zahl im Arrange ändern musste, hatte ich am Ende 8 Tests. Die mit allen „normalen“ Refaktorisierungsbemühungen immer noch einen recht großen Umfang besaßen.

Dies würde ich nachträglich als den zuvor genannt Twist an der Sache sehen. Denn einer der größten Kritikpunkte an TDD ist doch, dass wir viele Tests generieren die man irgend wie kontrollierbar halten muss. Genau dieses Problem ist es auch das viele Leute von TDD abhält. Statt als Hilfe zu dienen werden die Tests als Last wahrgenommen.

Was kann man also machen um die Last zu verringern? Wie kann ich das Arrange sauber auslagern wenn sich an den Testdaten kaum etwas ändert? Welche Hilfsmittel bieten mir die Frameworks die ich einsetze?

Alles Fragen die man wunderbar während eines Dojos diskutieren kann. Wichtig ist aus meiner Sicht aber, dass ein erfahrener Entwickler im Notfall Rede und Antwort stehen kann. Ein Umstand der aber für die meisten Katas gilt.

Zusammenfassung

Zusammenfassend finde ich die Kata sehr interessant. Das Szenario und die Regeln sind den meisten Leuten bekannt und die umzusetzende Logik nicht sonderlich schwer. Statt also lang über die Umsetzung als solche zu diskutieren, ist man eher gezwungen sich mit den Tests auseinander zu setzen, denn aufgrund der großen Zahl an Code-Dopplungen wird genau hier der Schwerpunkt für die Refaktorisierung liegen.

Meine Ideen dazu werde ich in etwa einer Woche hier posten und hoffe derweil mal auf den einen oder anderen Kommentar.