Testen, testen, testen

Schreib‘ die Tests, die du auch lesen magst

Tests sind ein sehr wichtiger Bestandteil des Entwicklungsprozesses. Daher habe ich mir ein paar Vorträge zu dem Thema ausgesucht.

Als erstes kam “Schreib‘ die Tests, die du auch lesen magst!” - hier wurden Prinzipien zum besseren Schreiben von Tests vorgestellt. Auch einfache Regeln, wie aussagekräftige Variablen- und Methodennamen, kurze Klassen und Methoden und Scope-bezogene Tests wurden genannt. Weitere Best-Practices sind die klare Trennung von Setup, Ausführung und Prüfung der erwarteten Ergebnisse und die Nutzung von DataProvider.

Da wir alle diese Regeln schon lange bei der täglichen Arbeit in JobRouter anwenden und für selbstverständlich haben, war der Vortrag für mich etwas zu einfach gehalten. Ich hätte mir etwas komplexeren Beispielen gewünscht

Im nächsten Vortrag wurde das Problem von langlaufenden Test-Suiten angesprochen. Bei großen Projekten mit vielen automatischen Tests kann die Laufzeit von einer Stunde bis zu mehreren Monaten dauern (z. B. Tests für komplexe Anwendungen in der Luftfahrt- oder Autoindustrie). Dies lässt sich schwierig mit den kurzen Zyklen der agilen Entwicklung vereinbaren.

Im Vortrag wurde das Alternativverfahren „Test-Impact-Analyse“ vorgestellt. Dabei werden nur diejenigen Tests zur Ausführung ausgewählt, die tatsächlich den zuletzt geänderten Code durchlaufen. Denn nur diese können eventuelle neue Fehler aufdecken. Zudem werden die ausgesuchten Tests so sortiert, dass die, die am meisten ungetestete Änderungen abdecken, zuerst ausgeführt werden. Dadurch sollen Fehler möglichst früh erkannt und somit schneller behoben werden.

Momentan laufen unsere Test-Suiten in annehmbaren Zeiten, aber solche Forschungen werden uns bei einer wachsenden Codebasis bestimmt helfen können. Allerdings, wenn wir stärker den Code modularisieren (z. B. in Bundles, Plugins o. Ä.), können auch die Test-Suiten kleiner gehalten werden - und sind dadurch schneller ausführbar.

Bei diesem Praxisbericht ging es um die Qualitätsverbesserung eines Projekts mit viel Legacy Code und wenig Testabdeckung. Unit-Tests nachzuziehen ist keine leichte Aufgabe, manchmal sogar unmöglich, ohne die eigentlichen Klassen zu verändern. Daher wurde entschieden, die Logik mit Akzeptanztests abzudecken, die eher die Business-Logik abbilden wie die Unit-Tests. Und wer kennt die Business-Logik am besten, wenn nicht der Product Owner?

Daher wurden die Tests bei diesem Projekt anhand der vom Product Owner gelieferten Daten mit cucumber geschrieben. Dazu braucht man keine Developer Skills.

Leider ist die JobRouter® Code-Basis nicht so simpel wie in dem vorgestellten Projekt bzw.  gab es in diesem Beispiel keine Abhängigkeiten zwischen der Datenbank und sonstigen externen Ressourcen. Daher ist das Schreiben und die kontinuierliche Ausführung von Akzeptanztests bei uns etwas komplexer.

Als letzten Vortrag in dieser Reihe habe ich mir eine Methode zum explorativen Testen in der Gruppe angeschaut - Mob-Testing. Dabei werden umgesetzte Features nicht nur von ein bis zwei Testern getestet, sondern von einer Gruppe (Mob) in gemeinsamen Test-Sessions. Die Akteure sind:

• ein Driver - führt die zu testende Aktion aus
• ein Navigator - gibt Anweisungen an dem Driver
• Mob - eine Gruppe aus Personen, die mögliche Test-Szenarien besprechen und an dem Navigator vorschlagen. Ein Mitglied des Mobs protokolliert die Testergebnisse.
• ein Moderator - achtet auf die richtige Durchführung der Session. In der Regel wird die Rollenbesetzung in bestimmten Zeitintervallen gewechselt (z. B. jede 5 Minuten wird der Navigator zum Driver, jemand aus dem Mob zu Navigator, der Driver wechselt in den Mob oder den Moderator aus)

Vorteile dieses Testverfahrens sind z. B. Wissenstransfer (jüngere Teammitglieder lernen worauf sie bestimmten Produktfunktionen achten sollen) und die viel größere Absicherung, dass beim Testen etwas vergessen oder übersehen wird (Mehraugenprinzip).

Die Idee fand ich sehr gut, besonders für komplexere Features, die viele Bestandteile des Produkts umfassen. Außerdem, haben wir ähnliche Akteure und Vorgehen wie beim Pair Programmlng und Team-Code-Review, also es passt dazu. Würde mich freuen, wenn wir es demnächst im Team ausprobieren können.