Coding Dojo II am 04.05.2010

Teilnehmer

Rico, Robert, Marco und Mike

Dojo-Organisation

Mike stellte an diesem Abend drei Aufgaben zur Auswahl. Die FizzBuzzKata vom letzten Dojo wäre, da waren wir uns einig, ein lohnendes Ziel. Wir beurteilten und analysierten den Quelltext des letzten Dojos. Eine willkommende Maßnahme für Marco, denn er kannte die Ergebnisse unseres letzten Dojos noch nicht. Aufgabe zwei war die DictionaryReplacerKata und als letztes die wohlbekannte LoCCounterKata. Nun waren wir am Zug.

Review der FizzBuzzKata

Die FizzBuzzKata aufrollen? Gut wäre es, aber ist sie nicht doch schon ausreichend gelöst? Marco's Einwand, der eine(!) Test wäre doch sehr nicht sehr anschaulich FizzBuzzer zu beschreiben fand Zustimmung. Zumal ein Vergleich eines Substrings gegen ein Ergebnis einer Methode doch ein wenig Bauchschmerzen verursacht.

Mike erwähnte die Klasse FizzBuzzer statisch zu markieren. Es vereinfache den Einsatz der Methoden innerhalb der Klasse. Statische Klassenmitglieder fördern die Trennung von Daten(strukturen) und Verhalten(Funktionen). Damit werden die Methoden unabhängig von Objektinstanzen einsetzbar. Das gefiel Robert nicht. Sein Argument: statische Klassen machen den Einsatz von IoC Container und entsprechenden Frameworks schwierig. FizzBuzzer ist eine Serviceklasse und könne über ein IoCContainer Framework mit seinen Möglichkeiten des Objektlivecyles und so weiter instanziert werden. Bei statischen Klassen können wir diese Möglichkeiten nicht mehr anwenden.

Wie seht ihr das?
Ist es berechtigt, dass Klassen-Design unter Berücksichtigung eines IoCContainer-Frameworks anzupassen oder nicht anzupassen?
Wann macht der Einsatz von IoCContainer Sinn?
Ab welchem Punkt macht der Einsatz von IoCContainern Sinn?
Sollten wir beim Design den Einsatz von IoCContainern berücksichtigen?
Welche Rolle spielen IoCContainer als Bewertungs- und techisches Hilfmittel einer Komponentenentkopplung?

1 Stunde Diskussion später waren wir mit der Beurteilung der FizzBuzzKata nur begrenzt weitergekommen. Statische Klasse, statische Methoden vs. Einsatz von IoCContainer, Integrationstests vs. Unittests am konkreten Falle FizzBuzzer.cs. Dennoch, Raum für Diskussion muss sein.

Nach einer kurzen Pause entschieden wir uns die LoCCounterKata umzusetzten. Eine schöne Aufgabe und hier gibt es Vergleichslösungen :-). Robert saß am Keyboard und war unser Code-Monkey. Die Aufgabenbeschreibung zur LOCCounterKata findet ihr hier.

Vorgehen

Vieles konnten wir aus dem letzten Dojo übernehmen. Das Anwendungsdesign, die Projektstruktur, das Test-Framework, die Code-Repository. Es ging diesmal sofort los. Verzeichnisstruktur und Projekte erstellen, konfigurieren und los... Coden!

Anwendungsarchitektur/-design
Im Vergleich zur FizzBuzzKata gab es keine nennenswerten Änderungen. Wir verblieben also beim gleichen Anwendungsdesign.




Code-Repository
Unser LoCCounterKata findet ihr wieder auf GitHub.com.

Projektstruktur


Doc = Dokumente
Lib = externe Bibliotheken
LOCCounter = Konsolenanwendung
LOCCounterCore = Domainlogik
LOCCounterTest = Tests

Das Naming der Verzeichnisse und der Komponenten lief besser, eindeutiger. Gut so!

Definition von Schnittstellen (Anwendungsgrenzen)
Dieses Thema wurde an diesem Abend nicht angesprochen. Eine explizite Definition von Anwendungsgrenzen war somit für uns kein Thema beim lösen der LoCCounterKata.

Klärung von Grenzfällen
Auch hier haben wir im Vorfeld nur am Rande über Grenzfälle gesprochen. Sie wird es geben, aber erstmal können wir doch die einfachen Fälle umsetzten! Robert hatte bereits eine gute Idee zur Umsetzung.

Test-getriebene Entwicklung
Auch diesen Abend waren wir uns einig - Test-getrieben, klar!
Nun, aber wie? Eine halbstündige Diskussionen um Wirtschaftlichkeit, Menge, Tiefe, Zweck, Sinn, Was, Wann, Wie ist obligatorisch. Unit- vs. Integrations- vs. Akzeptanztests eine Thematik die reflexartig zu einer Diskussionen führt!?!

Aufwandsabschätzung
Uns war klar - das schaffen wir nicht in 45 Minuten. Eine konkrete Zeiteinschätzung war an diesem Abend allerdings kein Thema.

Umsetzung

Nachdem wir ca. 60 Minuten Review der FizzBuzzKata hinter uns gelassen hatten, ging es los. Robert saß am Keyboard wir starteten mit dem dem ersten Test.
[TestFixture]
    public class LOCCounterTests
    {
[Test]
        public void Should_read_lines()
        {
            Assert.That(LOCCounter.Count("sampleFile.cs"), Is.EqualTo(17));
        }
    }

Nach Umsetzung der Klasse LOCCounter und der Methode Count (statisch) als Stubs starteten wir den Test - ROT - Klar. Nun wie weiter?
Die Methode weiter implementieren bis sie GRÜN wird, oder Unit-Tests auf die internen Methoden der Klasse LoCCounter?
Hier ergab die bereits erwähnte kontroverse Diskussion um mögliche Test-Strategien (Integrationstests vs. Unittests), eine Umsetzung mit Hilfe von separierten Unit-Tests.

Eine eigene Testklasse machte den Anfang:

[TestFixture]
    public class LOCCounterFilterTests
    {
[Test]
        public void Filter_empty_lines()
        {
            var lines = new String[] {" ", "some line content"};
            Assert.That(lines.FilterEmptyLine().Count(), Is.EqualTo(1));
        }

[Test]
        public void Filter_singleline_comment()
        {
            var lines = new String[] { " ", "// jkljljk " };
            Assert.That(lines.FilterSingleLineComment().Count(), Is.EqualTo(1));
        }

[Test]
        public void Filter_multiline_comment()
        {
            var lines = File.ReadAllLines("SampleFileMultiLineComment.cs");
            Assert.That(lines.FilterMultiLineComment().Count(), Is.EqualTo(8));
        }
    }

Einer Test-getriebenen Entwicklung stand jetzt nichts mehr im Wege. Das methodisch pragmatisches Vorgehen kann beginnen:
  • Unit-Test für den nächsten Filter schreiben (evtl. Test-Datenstruktur generieren) ->
  • Filter-Methode implementieren ->
  • Unit-Test für die Filter-Methode starten GRÜN == ja ->
  • Alle Filter-Tests starten - Alle GRÜN == ja ->
  • Methode in Count-Methode einhängen ->
  • Count() Integrationstest starten. GRÜN == nein ->
  • nächsten Filter implementieren
  • Count() Integrationstest GRÜN == ja -> FERTIG!
Leider sind wir an diesem Abend zu keinem wirklichen Ergebnis gekommen, da die Einbindung in die Konsolenanwendung nicht implementiert wurde. Die Domain-Logik lässt sich bisher
ausschliesslich über die Test-Methoden starten und stellen damit keinen Kundennutzen her.

Fazit

Es hat wieder einmal Spaß gemacht. Der Dojo-Organisator achtet das nächste mal besser auf die Timeboxen. Dieser Abend war doch sehr lang (23:00 Uhr) und das sollte
sich so schnell nicht wiederholen.


Wir haben wieder dazu gelernt, diskutiert, Erfahrungen ausgetauscht, vorallem geübt und somit unser können verbessert.

Ein gelungender Abend! Weiter so! Wir freuen uns auf das nächste Dojo!




Comments