Archiv für den Monat April 2013

TDD 2.0

Ralf Westphal schreibt in seinem Artikel Ab ins Grüne in der dotnet pro Ausgabe 04/2013 über die Probleme mit TDD. Auf den Punkt gebracht, schildert er seinen Eindruck, dass die Fokussierung auf T(est)D(riven) einen Lösungsansatz perpetuiert hat, der D(evelopment) zu wenig bis gar nicht integriert. Will heißen: Durch die Konzentration auf das Schreiben und Lösen der Tests, wird die Analyse- und Lösungsphase fast gänzlich außer Acht gelassen. Deshalb stünden, so seine Meinung, in Coding Dojos am Ende auch nur selten fertige Ergebnisse.

Aus meiner Sicht trifft Ralf damit voll ins Schwarze. Persönlich störte ich mich seit längerer Zeit an diesem Problem. Ich denke sogar, dass das Development der weit schwierigere Teil ist. Test zu schreiben und den Code dafür entsprechend zu präparieren ist eine Art Training wie das Lösen von Gleichungen 2ter Ordnung in der Schule. Je nach Kenntnisstand des Entwicklers werden noch Vereinfachungen oder schnellere Lösungsansätze wie die binomische Formel erkannt. Ein solides Level stellt sich allerdings nach relativ kurzer Zeit ein. Neue Probleme wie Gleichungen vierter Ordnung bedürfen aber der analytische Fähigkeiten.

Deshalb haben wir bei unseren Coding Dojos die Anregungen aufgegriffen und implementiert. Interessanterweise, was ich persönlich als sehr positiv empfinde, gab es im ersten Dojo mit dem neuen Verfahren keine einzige Codezeile, da eine Stunde lang das Problem eruiert und Begrifflichkeiten diskutiert wurden. Wohlgemerkt handelte es sich dabei um ein echtes Szenario aus einer unserer Problemdomäne, d.h. wir verwendeten keine der üblichen Katas. Umso schneller kamen wir dann im zweiten Training zu einer fertigen Lösung. Mit ein wenig Überziehung erreichten wir nach 1.15h die Ziellinie.

TDD 2.0 empfinde ich als längst überfällige Erweiterung bzw. Kritik. Wir werden in Zukunft auf diese Weise weiterarbeiten. Ein Punkt, der für mich allerdings weiterhin in Frage gestellt werden sollte: Müssen Coding Dojos an Katas durchgeführt werden? Warum nicht an einem echten, auf ein notwendiges Minimum reduzierten Praxisbeispiels aus der Problemdomäne trainieren? Oder alternativ für die Administration ein kleines Hilfsprogramm schreiben, dass die tägliche Arbeit automatisiert? Kürzlich half ich meinem ehemaligen Fussballverein beim Realisieren des DFB Reglements bzgl. Stammspieler. Gelöst habe ich es vorerst über Excel, sodass immer noch Handarbeit seitens des Vorstands notwendig ist. Doch dieses Thema kommt auf unsere Coding Dojo Agenda. Es gibt viele gemeinnützige Organisationen oder Sportvereine, die sich über Hilfe der IT zu kleinen Wehwehchen freuen würden!

FakeItEasy und Castle.Core

Es ist vollbracht. Das Team um FakeItEasy hat endlich die Abhängigkeit zu Castle.Core entfernt, indem es selbige mit IL Merge in die eigene DLL gepackt hat. Damit lassen sich Castle und FakeItEasy NuGet Packages separat updaten.

Vorher: image

PM> Install-Package FakeItEasy -Version 1.7.4626.65
Attempting to resolve dependency ‚Castle.Core (≥ 3.1.0.0)‘.
Successfully installed ‚Castle.Core 3.1.0‘.
Successfully installed ‚FakeItEasy 1.7.4626.65‘.
Successfully added ‚Castle.Core 3.1.0‘ to FakeAndCastle.
Successfully added ‚FakeItEasy 1.7.4626.65‘ to FakeAndCastle.

 

Nachher:

image   PM> install-package FakeItEasy
   Successfully installed ‚FakeItEasy 1.10.0‘.
   Successfully added ‚FakeItEasy 1.10.0‘ to FakeAndCastle.

 

 

 

 

Zurückzuführen ist das auf ein großes Interesse seitens der Community. Auf meine Bitte hin wurde in die aktuelle Version 1.10.0 Castle.Core 3.2.0 integriert.

 

Good job, guys!

%d Bloggern gefällt das: