The Bandt way of TDD

Jürgen Gutsch — Fri, 07 May 2010 11:44:00 GMT

Seit einiger Zeit baue ich nebenher an einem kleinen multi-mandantenfähigen Lizenzserver. Ziel ist es diese Anwendung komplett mit TDD zu schreiben.

Wie ich sicher bisweilen schon erwähnt hatte, war es bisher für mich sehr schwer, TDD wirklich konsequent einzusetzen. Wenn man Jahrelang auf die herkömmliche Art und Weise programmiert, ist es in einem kleinen privaten Projekt ein enormer Kraftakt, sein Denken so umzustellen, dass man

Erst penibel die Anforderungen definiert
Die Tests definiert
Die Tests schreibt
und dann implementiert, ohne zu viel Code zu schreiben

Allerdings hat mir ausgerechnet folgender Blogbeitrag von Thomas Bandt den Anstoß gegeben es noch einmal ernsthaft zu versuchen: TDD, BDD - Status Quo

The Bandt way of TDD

Das interessante an diesem Weg ist, dass ich einen Schritt spare: Die Anforderungen sind schon die Definitionen der Tests und das sogar Wort wörtlich. Die Anforderungen werden im Klartext, auf deutsch mit allen Umlauten als Test geschrieben. Das vereinfacht das schreiben der Tests ungemein.

Der zweite interessante Punkt ist die Kapselung wiederkehrender Aufgaben (erzeugen des SuT und der abhängigen Stubs) in eine Basisklasse.

Es flutscht

Also hatte ich beschlossen den Lizenzserver (den ich schon länger schreiben wollte) mit dem Bandt way of TDD zu entwickeln. Interessanterweise habe ich mich bei diesem Projekt bisher noch nicht dabei erwischt, an den Tests vorbei zu implementieren. Und noch schlimmer: Es fängt an Spaß zu machen, wenn man alle Tests die sich inzwischen angesammelt haben, laufen lässt und alles grün ist.

Word to Code

Nach dem die Zahl der Tests nun ständig ansteigt, habe ich mir so langsam Gedanken gemacht, wie ich diese dokumentiere. Bisher hatte ich (da es sich um ein rein privates Projekt handelt) die Anforderungen direkt in Tests umgesetzt, und dann nach einer Weile alle Definitionen der Tests in einer HTML-Datei gespeichert.

Aber die bessere Lösung stammt wieder einmal von Thomas: mit "Word to Code" hat Thomas ein kleines Helferlein geschrieben, mit dem sich in Word formulierte Anforderungen, nach den Konventionen des Bandt way of TDD, in fertige Unit Tests konvertieren lassen.

Fazit

Wer also, wie ich, selber noch Schwierigkeiten hat, TDD wirklich einzusetzen, sollte mal diesen Weg probieren. Sobald man richtig mit den Mocking und Testing Frameworks seiner Wahl vertraut ist, flutscht es wirklich. Den Aufwand den man auf die Herkömmliche Art noch ins Debugging und ins testen von Hand gesteckt hat, steckt man nun mit TDD in die Tests. Die Tests geben einem zusätzlich noch die Sicherheit, dass der eigene Code den Anforderungen entspricht :-)

Einfach mal ausprobieren :-)

Eines führt bekanntlich unweigerlich zum nächsten

Jürgen Gutsch — Sat, 17 Jan 2009 12:58:00 GMT

Vor einigen Tagen fragte mich Peter ob ich MbUnit kennen würde, ein – wie er sagte – einfaches und vor allem gut erweiterbares Unit Testing Framework.

Ich kannte es nicht, also folgte das nächste: Ich Google nach MbUnit und folge auf der Projektseite dem Link zur neuesten Version (v3) und lande bei Gallio. Der Download bei Gallio ist ein Bundle, bestehend aus MbUnit und vielen weiteren Test-Tools.

Es folgt wieder unweigerlich das nächste: Ich lade mir das gesamte Paket herunter und schaue mir die enthaltenen Beispielprojekte an, bzw. starte einfach mal eines der Unit-Test-Projekte. Das interessante war jetzt, dass selbständig der Internet Explorer auf geht, Google aufruft, “MbUnit” in das Suchfeld eingetragen wird und anschließen mit einem Click auf den Button “Auf gut Glück” zur Projektseite von MbUnit gesprungen wird.

Das führte wiederum dazu, dass ich in diesem Testprojekt die WatiN Library gefunden habe (WatiN = “Web Application Testing In .Net”). WatiN ermöglicht es in einem Unit Test-Projekt, den Internet Explorer anzusteuern und Aktionen direkt auf der zu testenden Seite durchzuführen. Man kann dem Internet Explorer also sagen: “öffne mir folgende Seite, klicke auf folgenden Link und prüfe ob auf der Seite folgender Text zu finden ist”.

Und es folgte darauf hin unweigerlich dazu, dass ich mir sagte: “Hei Jürgen, das ist ja so cool, das kannst du doch für das sharpcms gebrauchen. Damit kannst du ja das Backend komplett mit Tests abdecken”. Also nutze ich jetzt jede freie Sekunde (was für mich ja bekanntlich recht schwierig geworden ist. Siehe hier) um Tests mit MbUnit und WatiN für das sharpcms zu schreiben.

Und wer ist schuld, dass das sharpcms jetzt automatisierte Tests bekommt?
Natürlich der Peter ;-)

@Peter: Danke nochmal für diesen Hinweis :-)

Search results matching tags 'Tools' and 'Unit-Tests'

The Bandt way of TDD

Eines führt bekanntlich unweigerlich zum nächsten