Darum habe ich die allseits beliebte FizzBuzz Kata in Javascript mit dem Jasmine BDD Framework umgesetzt. Wer die Regeln von FizzBuzz nicht kennt, kann sie hier nachlesen.

Meine Ziele waren folgende:

• Javascript Syntax intuitiver niederschreiben können
• Testgetrieben entwickeln
• Das ganze sollte auch noch ein annehmbares Tempo haben
• Netbeans Shortcuts anwenden (Maus nicht verwenden)

Da ich mich momentan sehr für Qualität in der Softwareentwicklung interessiere, darf das Unit Testing natürlich nicht fehlen. Mit PHPUnit konnte ich nun schon einige sehr positive Erfahrungen machen. Da auch viele PHP Projekte mit Javascript arbeiten, suchte ich deshalb auch nach einen Testwerkezeug für JS.
Auf der Webseite Test Driven Websites bin ich auf einen schönen Javascript Unit Testing Framework Vergleich gestossen. Der Favorit war ganz klar JsTestDriver und nach einigem weiteren Surfen im Netz, hat sich für mich dieser Eindruck bestätigt. Da es sehr viele Test Frameworks für Javascript gibt, habe ich den allgemeinen Eindrücken im Netz einfach vertraut und mich für JsTestDriver entschieden.

Highlights von JsTestDriver

• xUnit konformer Syntax (sprich, der Syntax lehnt sich an PHPUnit oder Junit an)
• Die Tests benötigen kein HTML File, wie in anderen JS Testframeworks
• Client/Server Architektur für Tests (Das Prinzip ist ähnlich wie bei Selenium) -> Der Test-Server muss somit nicht lokal laufen
• Durch die Client/Server Architektur können mehrere Browser gleichzeitig getestet werden
• Plugin für Eclipse und IntelliJ IDEA – bei jedem Save werden die Tests automatisch durchgeführt
• Plugin Architektur – JsTestDriver bietet Plugins um andere Unit Testing Frameworks oder auch Mocking Frameworks zu integrieren
• Problemlos in Continuous Integration Prozess integrierbar

Stolpersteine

• JsTestDriver besitzt keine Möglichkeit zu mocken (ok, alle anderen JS Frameworks auch nicht). Es kann aber problemlos ein Mocking Framework eingebunden werden
• Achtung bei globalen Variablen/Funktionen/Objekte – werden die globalen Variablen beim Testdurchlauf überschrieben, haben sie beim nächsten Durchlauf immer noch den überschriebenen Wert. Dies gilt so lange, bis entweder der Server neu gestartet wird, oder das Source File, wo die Variable deklariert wurde verändert wird. Der Grund ist Performance: Der Server cacht alle .js Dateien und lädt sie nur neu, wenn eine Datei auch verändert wurde.

Installation

Auf der JsTestDriver Homepage, wird sehr einfach beschrieben, wie man das Framework installieren und konfigurieren kann.
Auf der Homepage von James Carr erfährt man weitere nette Details über JsTestDriver.

Code Example

TestCase("MyTestCase", {
    setUp: function() {
        //...
    },

    testAssertionWithMessage: function() {
        assertTrue("this is not true", false);
    },

    testAssertionWithoutMessage: function() {
        var actual = 5;
        assertEqual(5, actual);
    },

    tearDown: function() {
        //...
    }
};

Fazit

JsTestDriver ist für mich absolut empfehlenswert. Ich konnte mich dank den PHPUnit Kenntnissen sehr rasch im Framework zurechtfinden und hatte schon nach kurzer Zeit die ersten Tests geschrieben. Die grössten Vorteile sind für mich: CI, erweiterbar mit anderen Frameworks, Multibrowsertesting

Es handelt sich dabei um Clean Code von Robert C. Martin. Als ich die ersten Seiten des Buches gelesen habe, habe ich bereits meine ersten Erkenntnisse in einem Blogeintrag niedergeschrieben.

Einführung

Im ersten Kapitel nimmt Robert C. Martin kein Blatt vor den Mund. Er beschreibt sehr schön, wie schnell die Spezies Softwareentwickler die Schuld von schlechtem Code auf andere abschiebt (Zeitmangel, Chef usw.). Wir sind aber schliesslich die Profis und sollten dementsprechend unser Werk verteidigen.

Er beschreibt auch, warum wir uns so verhalten und warum es so schwierig ist guten Code zu schreiben. Erstens ist den meisten gar nicht bewusst, dass guter und sauberer Code längerfristig enorm wichtig ist und zweitens wissen viele auch gar nicht, was sauberer Code ist.

Wie mache ich es richtig

In den nächsten Kapitel beschreibt Martin sehr detailliert wie man es richtig macht.

• Wie wählt man aussagekräftige Namen für Variablen, Methoden usw.
• Wie sollten Funktionen strukturiert sein (Grösse, Komplexität usw.)
• Was sind gute und was sind schlechte Kommentare
• Wie sollte man seinen Code formatieren
• Der Umgang mit Objekten und Datenstrukturen
• Wie sollte man Error Handling anwenden
• Wie sollte man Schnittstellen verwenden
• Wie sollte man Klassen aufbauen
• Wie baut man ganze Softwaresysteme
• Warum benötigt man Unit Tests

Martin drückt auch klar aus, dass saubere Namensgebung, Unit Testing und Refactoring die zentralen Erfolgsrezepte für gute und vor allem langlebige Software sind.

Refactoring

Bis jetzt konnte man nur konsumieren. Im nächsten Teil des Buches muss man aber selber mitdenken. Martin beschreibt Schritt für Schritt, wie er Klassen von bekannten Projekten “refaktorisiert”. Dieser Teil bringt einem nur dann etwas, wenn man sich intensiv mit dem abgedruckten Code beschäftigt.

Code Smells

Im letzten Teil des Buches fasst Martin nochmals alle Code Smells (Dinge, die Code schlecht machen) zusammen, welche man während der ganzen Zeit erarbeitet hat.

Mein persönliches Fazit

Für mich ist dieses Buch unglaublich wertvoll. Im ersten Teil wurde mir bewusst gemacht, warum wir als Entwickler so reagieren, wie wir es tun. Und danach wird schön beschrieben, wie man es richtig macht.

Ich wusste immer, dass etwas falsch läuft beim programmieren und das ich bzw. meine Kollegen unsauberen Code schreiben. Nun kann ich endlich sagen, was es ist und wie man es besser macht. Das hilft auch bei Diskussionen mit Kollegen, wenn man ihren Code begutachtet und begründen kann, warum ihr Code nicht so “optimal” ist.

Die theoretischen Konzepte hinter TDD habe ich beim lesen schnell verstanden und dachte auch, dass dies eine gute Sache ist. Es kostet aber dennoch einige Überwindung um richtig mit TDD zu beginnen. Nur allzu schnell fällt man in alte Muster und entwickelt einfach drauf los, weil man sich noch nicht so gut mit TDD und dem Testing Framework auskennt.

Folgende Entwicklungsschritte und Erkenntnisse habe ich durchlaufen:

Schritt 1 – TDD in der Theorie

Theorie über TDD gelesen und gedacht: “Wow, das erscheint mir logisch, das muss ich auch mal ausprobieren”.

Schritt 2 – Fizzbuzz mit TDD entwickelt

Nachdem ich Bücher gelesen und einige Tutorials gesehen habe, habe ich mich an das erste reale Übungsszenario gemacht. Die Umsetzung der simplen Aufgabe Fizzbuzz fiel mir recht leicht und meine Erkenntnis zu diesem Zeitpunkt war, dass TDD relativ easy ist

Schritt 3 – TDD mit Brownfield Code

Voller Elan ging ich in mein Geschäft und dachte mir: “So, fangen wir mit TDD an”.

Relativ schnell bemerkte ich, dass ich es irgendwie nicht fertig brachte, Tests für meine zu testenden Funktionen und Klassen zu formulieren. Diese waren so stark gekoppelt, so dass ich nicht einzelne Funktionalitäten testen konnte, sondern alles instanzieren und einbinden musste. Sinn und Zweck von TDD ist ja, dass man ganz spezifische Funktionen testet und eben nicht das, was sonst noch so alles dran hängt.

Ausserdem bemerkte ich, dass ich mich in der Anwendung des Testing Frameworks noch unsicher fühle (Ich kannte zwar einige Funktionen, dachte aber, dass es da wohl noch mehr gibt ). Daher nahm ich mir vor, zuerst nochmals das PHPUnit Manual durchzuackern, vielleicht ergeben sich dadurch einige Erkenntnisse, wie man gekoppelte Funktionen testen kann.

Schritt 4 – Das PHPUnit Manual

Ok, wieder zurück zur Theorie. Habe das PHPUnit Manual durchgeackert und herausgefunden, dass es doch noch 2 oder 3 gute Funktionen neben $blubb->AssertEquals() gibt

Eine wichtige Erkenntnis war, dass man Klassen und Funktionen “mocken” kann. Das bedeutet, dass man für ganz bestimmte Funktionsaufrufe definieren kann, was man für Ergebnisse zurückerwartet.

Das “Mocken” ist zum Beispiel sinnvoll, wenn man mit Daten aus einer Datenbank arbeitet. Wenn man Tests formuliert, weiss man ja nicht wirklich, was genau in der Datenbank steht und die Tests sollen ja auch  nicht davon abhängen,wenn man die Funktion, welche diese Daten verarbeitet sollen, testen will. Also definiert man die Rückgabewerte der Datenbankwerte einfach mittels mocks.

Schritt 5 – TDD mit Brownfield Code – Part 2

Ok, wieder zurück im Geschäft und bereit für’s mocken. Habe zuerst einmal den Datenbanklayer gemockt und dann die ersten Tests geschrieben, mit Erfolg. Nachdem ich aber einige Funktionen und Objekte gemockt habe, setzte sich die Erkenntnis durch, dass es trotzdem schwierig ist, Tests für bestehenden Code zu schreiben.

Warum?

1. Der Code ist untereinander so verknüpft und teilweise auch unsauber, dass es sehr viel Zeit benötigt überhaupt einen vernünftigen Test zu generieren

2. Durch den Zeitdruck sagt man sich schnell mal: “ok, dass mach ich jetzt noch kurz ohne TDD, ich habe ja Stress”.

Schritt 7 – TDD mit Brownfield Code – Refactoring

Ich beschäftigte mich weiterhin in der Theorie mit TDD und Clean Code. Bei der Arbeit schaffte ich es durch den Zeitdruck aber noch nicht, konsequent TDD anzuwenden.

Inzwischen hatte ich für einige Funktionen Tests geschrieben und diese waren auch alle grün. An einem Wochenende startete ich eine Übungssession für TDD und nahm mir den Brownfield Code vom Geschäft vor. Da ich überhaupt nicht zufrieden mit dem Code war, entschied ich mich für ein Refactoring einer Klasse, für welche bereits Tests bestanden. Zu Hause hatte ich ja auch keine Datenbankanbindung und auch keine saubere Umgebung. Somit konnte ich beim Refactoren die Applikation nie ausführen (also im Browser laufen lassen).

Ich war also am Refactoren und meine Tests waren stets erfolgreich (nach einigem Üben). Am Montag wieder zurück im Geschäft spielte ich die neue Klasse ein und “bäm” die Refactorte Klasse lief ohne Probleme.

Das war für mich endgültig die Erkenntnis, dass es ohne TDD nicht mehr geht und dass man mit TDD einfach bessere und fehlerfreiere Software entwickeln kann.

Erkenntnisse

Zitat Robert C. Martin: “Nur Software die getestet werden kann ist gute Software”.

Im Endeffekt geht es nur darum gute Software zu entwickeln. Welches Instrument man schlussendlich verwendet ist egal. Meine persönliche Erkenntnis ist aber, dass TDD die Entwicklung von guter Software ermöglicht.

• TDD fördert die Testbarkeit, weil man vorher schon den Tests dafür schreibt
• TDD fördert entkoppelte und komponentenbasierte Software und ergibt somit bessere Software
• TDD auf der grünen Wiese ist deutlich einfacher, als mit Brownfield Code
• TDD muss man einfach ausprobieren und anwenden – am Anfang muss man sich konsequent zwingen es anzuwenden. Mit der Zeit ergibt sich ein aha-Effekt in der Praxis und man sieht, dass TDD unglaubliche Vorteile gegenüber der normalen Entwicklung hat
  • Man entwickelt entkoppelte Funktionen
  • Man fühlt sich sicherer, weil man Tests hat
  • Bestehender Code kann ohne Probleme angepasst werden, weil man jederzeit weiss, dass die alte Funktionalität noch gegeben ist
• Wenn man konsequent mit TDD entwickelt, kann man eine Funktion in einem Brownfieldprojekt erst Refactoren, wenn man für die alte Funktion zuerst Tests geschrieben hat. Nur so kann die bestehende Funktionalität sichergestellt werden
• Ohne das Testing Framework gut zu kennen (in meinem Fall PHPUnit) kann man nicht mit TDD entwickeln

Lesetipps

Wenn ein Entwickler eine Idee für ein neues Feature hat, oder findet, dass man den alten Code umstrukturieren sollte treten immer wieder die gleichen Probleme auf. Kann ich den alten Code ohne Risiko anpassen, so dass die alten Programmteile nachher noch laufen? Wenn ich das Programm von Hand teste, habe ich wirklich an alles gedacht?

Hier setzt Test Driven Development (TDD) ein – also testgetriebene Entwicklung. TDD bedeutet, dass man für jedes Stück Code, dass man programmiert zuerst ein Test schreibt, somit ist man sicher, dass ein Programmteil auch getestet ist und funktioniert. Wenn man irgendwann die Funktion anpassen will, kann man nach der Veränderung einfach den Test laufen lassen und sich sicher sein, dass die Funktionalität immer noch die gleiche ist.

TDD folgt dem einfachen Grundsatz:

1. Test schreiben
2. Test durchlaufen – Test schlägt fehl
3. Code anpassen
4. Test durchlaufen – Test funktioniert
5. Code Refactoring

TDD ein bisschen mehr beschrieben:

1. Test schreiben für eine kleine Funktionalität
2. Test durchlaufen lassen und sehen, wie der Test fehlschlägt
3. Den Test so einfach wie möglich, durch hinzufügen einer Funktionalität im Code, zum laufen bringen (hierbei können auch Codesünden begangen werden, dass spielt in der 1. Phase keine Rolle)
4. Test durchlaufen lassen und sehen, wie der Test funktioniert
5. Code Refactoring – Code so korrigieren, dass er sauber ist / Code Redundanzen entfernen
6. (jedesmal wenn eine Änderung am Code gemacht wird, muss wieder bei 1 begonnen werden bis das Refactoring abgeschlossen ist)

Zu beginn dachte ich auch, dass dies ja viel Zusatzaufwand bedeutet. Aber man muss bedenken, dass die Funktionen ja sowieso getestet werden müssen, warum also nicht schon vorher definieren, was man testen will? Ausserdem hat man diese Tests auch in Zukunft und Veränderungen können sofort gecheckt werden, ohne dass man von Hand durchgehen und überlegen muss, ob dies auch wirklich funktionieren könnte.

Ich habe noch einen interessanten Link im Netz gefunden, der Anhand eines Videotutorials von FizzBuzz zeigt, wie Test Driven Development mit Java/Junit funktioniert.

Quellen
Buch Test-Driven Development by Kent Beck
Begriff Test Driven Development by Wiki