Schlüsselfaktoren für eine langfristig gute und qualitativ hochwertige Software sind:

• Kommunikation zwischen den beteiligten Personen (Projektleiter, Entwickler, Kunde)
• Automatisierung wo es nur geht -> Continuous integration
• Stimmung / Motivation im Team -> Der Wille sich ständig verbessern zu wollen
• Abdeckung der Software durch Tests -> Unit Tests, Integration Tests, …
• Kontinuierliches Refactoring -> Die Software ändert sich schliesslich immer
• Regelmässige Code Reviews
• Modularer und unabhängiger Aufbau der Softwarekomponenten

Es ist zwar etwas zusammengewürfelt, aber ich möchte einfach noch ein paar Gedanken zu den oben aufgezählten Punkten erwähnen.

Wenn das Programm läuft ist man nur halb fertig

Wenn man glaubt, das man mit einer Funktion fertig ist, hat man normalerweise etwa die hälfte geschafft (ausser man entwickelt mit TDD, da ist’s besser)Wenn bei uns die Lehrlinge jeweils sagen, dass sie fertig sind, frage ich sie:

• Ist der Code dokumentiert?
• Ist der Code mit Tests abgedeckt?
• Hat jemand ein Review von deinem Code gemacht?
• Hast du den Code schon refaktorisiert bzw. aufgeräumt?
• Läuft es auch auf einer anderen Installation?

Natürlich ist die Antwort eigentlich immer nein (wahrscheinlich wie bei den meisten Entwicklern). Man sollte sich also auch unter Zeitdruck immer fragen, ob die Aufgabe auch wirklich erledigt ist. Niemals sollte man sich damit zufrieden geben, dass es einfach nur läuft, auch wenn einem dies jemand anders so vermitteln will.

Modularer Aufbau von Software

Inzwischen bin ich der festen Überzeugung, dass Software modular aufgebaut und in kleine Teile unterteilt sein sollte. Viele kleine Legosteine, welche keine Abhängigkeiten haben, sind viel einfacher zu einem ganzen zusammenzufügen, also grosse und undurchschaubare Konstrukte. Zwei wichtige Prinzipien sind hier Separation of Concern und Dependency Inversion Principle.

Testen

Immer wieder höre ich, dass z.B. Unit Testing nur Zeit benötigt und eigentlich gar nicht soviel bringt. Diesem Punkte kann ich absolut nicht zustimmen. Testing ist etwas absolut essentielles.

Schreibe ich Tests, formuliere ich meine Anforderungen an die Funktion. Ausserdem stelle ich sicher, dass meine Architektur im kleinen gut ist (bei zu vielen Abhängigkeiten wird es schwierig überhaupt zu testen). Zudem muss ich keine Angst vor Refactorings haben. Aussagen wie diese gibt es nicht mehr: “Ich mach mal lieber nichts an dieser Funktion, ich weiss ja nicht, ob sie nachher noch funktioniert”.

Refactoring

Refactoring ist immer wieder nötig, da sich die Software auch ständig ändert. Wer kein Refactoring macht, sondern alles an das Bestehende anhängt, wird über kurz oder lang einen riesen Krüppel generieren.

Code Reviews

Code Reviews haben mehrere Vorteile. Man kann mit anderen kommunizieren und so auch seinen Horizont erweitern. Ausserdem sieht jemand anders häufig Fehler oder unklare Konstrukte, die einem so nie aufgefallen wären.

Zusammenhang zwischen Code Reviews, Modularität, Testing und Refactoring

Die Zusammenhänge ergeben sich eigentlich von alleine. Um gute Software, sprich unabhängige, modulare Software zu produzieren, muss man sie mit Tests abdecken. Da sich Software ständig ändert, muss sie Refaktorisiert werden, ohne Tests ist dies nicht ohne Fehler möglich. Die Code Reviews unterstützen diesen Prozess.

Heute möchte ich über das Thema Mocking unter Javascript schreiben. Wie schon bei den Testing Frameworks, gibt es auch einige Mocking Frameworks. Ich habe mich wieder über TestDrivenWebsites inspirieren lassen und mich für JsMockito entschieden, welcher ein Klon vom entsprechenden JMock für Java ist. Ich setze in diesem Artikel voraus, das JsTestDriver installiert und einsatzbereit, da JsMockito integriert wird.

Dieses mal hatte ich es aber nicht so einfach, bis ich die ersten funktionierenden Beispiele hatte. Folgend liste ich die wichtigsten Quellen auf, auf welchen ich Beispiele für JsMockito gefunden habe:

• JsMockito Homepage
• Sourcen auf Github
• JsMockito API

Da in den kurz gehaltenene Beispielen die Benennung der Variablen vielleicht nicht immer Ideal gewesen ist (vorallem beim Function Mocking), dauerte es eine Weile, bis ich begriffen hatte, wie das Mocking anzuwenden ist. Ich versuche darum nochmals ein Beispiel durchzuspielen und auf die wichtigsten Punkte einzugehen.

Installation

Es müssen die Sourcen von JsHamcrest (JsMockito baut auf JsHamcrest auf) und JsMockito heruntergeladen und über die JsTestDriver.conf eingebunden werden.

Danach folgt die Integration in JsTestDriver mittels

JsHamcrest.Integration.JsTestDriver();
JsMockito.Integration.JsTestDriver();

Das wärs schon, JsMockito sollte nun einsatzbereit sein.

Mocken von Objekten

Ich arbeite momentan an einem Projekt, bei dem loose Kopplung von Objekten und Funktionen nicht existiert. Sprich, es werden neue Instanzen ohne Dependency Injection erzeugt. Somit wird das Mocken noch um einiges erschwert.

Ich möchte nun anhand eines Beispiel zeigen, wie man die Abhängigkeiten mocken kann.

myapp = {
    Greeter: {
        greet: function(name){
           return "Hello " + name + "!";
        },
        goodbye: function(name){
            return "Bye " + name + "!";
        }
    }
};

Ich habe ein Objekt Greeter mittels Object Literals erzeugt.

Nun folgt der Test Code.

TestCase("GreeterTest", {
    setUp: function() {
        //tmp backup, because myapp.Greeter is global and the mock
        //is overwriting the methods i mock
        this.tmpObjectGreeter = myapp.Greeter;
    },

    testMockupObjectGreeter: function(){
        //prepare an object for mocking - some stubbing functions will be added
        //to the object
        myapp.Greeter = mock(myapp.Greeter);
        //if i call greet() - return value = "Hello Mockito"
        //else nothing is happening to other functions in the object
        //same behaviour as before the mock
        when(myapp.Greeter).greet().thenReturn("Hello Mockito!");

        assertEquals("", "Hello Mockito!", myapp.Greeter.greet("Mr. Johnson"));
        assertEquals("", "Bye Mr. Johnson!", myapp.Greeter.goodbye("Mr. Johnson"));
    },

    tearDown: function() {
        //Restore myapp.Greeter to original
        myapp.Greeter = this.tmpObjectGreeter;
    }
});

Da ich beim mocken das real existierende globale Objekt Greeter verändere, muss ich Greeter im setUp zwischenspeichern und beim tearDown wieder in den Originalzustand zurückversetzen. Wie schon im letzten Artikel über JsTestDriver erwähnt, werden veränderte Objekte, Funktionen und Variablen nicht mehr in den Originalzustand zurückversetzt, wenn die Tests erneut aufgerufen werden.

testMockupObjectGreeter zeigt nun auf, wie man ein Objekt mocken kann. Der wichtigste Teil ist die Zeile mit when()… Hier kann definiert werden, welche Funktionen im Objekt gemockt werden sollen und wie der Mock beim Aufruf reagieren soll. thenReturn ist der einfachste Fall. Hier wird definiert, dass egal wie greet() aufgerufen wird, immer “Hello Mockito!” zurückgegeben wird.

Dieses when/then Konstrukt ist sehr mächtig. Man kann beliebige Dinge zurückgeben – primitive Datentypen, Funktionen, Objekte usw.

Im zweiten Teil werde ich auf das mocken von globalen Funktionen eingehen und noch ein bisschen mehr über die Möglichkeiten mit when/then aufzeigen.

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

Kurze Erklärung zum Thema

Selenium ist ein browserunabhängiges Tool, um automatisierte Oberflächen-Tests in Webapplikationen zu generieren und dann auch durchzuführen. Es ist somit möglich, verhalten von Benutzern 1:1 nachzuspielen und in einem continuous integration Prozess zu verwenden.

Teil 1 – Einführung

Im ersten Teil des Buches wird eine Einführung zu Selenium dargelegt. Was gibt es in Selenium für Module und für welche Art von Tests kann das Tool verwendet werden.

Teil 2 – Die Selenium Module

Im zweiten Teil des Buches werden einem die verschiedenen Selenium Module und Selenese erklärt.

• Selenese -> Sprache
• Selenium IDE -> Firefox Plugin, um sich Tests einfach über den Browser zusammenzuklicken
• Selenium Remote Control -> Testsequenzen über einen Remote Server absetzen und ausführen
• Selenium Grid -> Ausführen von Tests auf mehreren Servern mit versch. Browsern und versch. Betriebsystemen

Teil 3 – Tips und Tricks + API

Im letzten Teil des Buches werden noch ein paar Tricks zu verschiedenen Themen aufgezeigt und am Schluss gibt es nochmals eine detaillierte Auflistung der API zu sehen.

Fazit

Das Buch listet alle Module und Befehle von Selenium auf und erklärt diese. Es ist sozusagen ein Selenium –help. Daher hielt sich meine Begeisterung während des Lesens auch in Grenzen.

Folgende Punkte wurden nicht oder nur in einigen wenigen Sätzen angesprochen:

• Was sind best practises für Oberflächentests?
• Wie wird ein solcher Oberflächentest sinnvollerweise aufgebaut?
• Was für eine Testabdeckung macht Sinn?
• Welche Teile einer Applikation sollten mit Oberflächentests getestet werden?
• Wie können/sollen Unittests mit Oberflächentests kombiniert werden?
• Wie können die Testergebnisse sinnvoll validiert werden?
• …

Unter Selenium HQ findet man die im Buch beschriebenen Infos auch, einfach auf Englisch.

Trotz der negativen Buchkritik ist Selenium ein sensationelles Instrument, um Oberflächentests zu automatisieren. Ich werde bei Gelegenheit noch einen Artikel darüber schreiben, wenn dies von euch gewünscht wird.

Weiterführende Quellen

• http://seleniumhq.org/

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