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.

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/