TDD für Fortgeschrittene - Teil 1: Motivation und Akzeptanztests

Der ganztägige Power-Workshop zum fortgeschrittenen Testen wird von Johannes Link und Tammo Freese organisiert. So steht es zumindest in der Ankündigung. Johannes ist aber krank. Also unterstütze ich Tammo bei der Betreuung der Übungen - so gut es eben ohne Vorbereitung und Kenntnis der Folien geht. Die Konferenzleitung hat 75 Teilnehmer geschätzt. Das passt auch ungefähr zur tatsächlichen Teilnehmerzahl.

Tammo beginnt mit der Motivation für Testen: Qualität der internen Struktur erhalten. Bei der testgetriebenen Entwicklung wird erst der Test geschrieben und dann der Produktivcode, der den Test erfüllt. Die Automatisierung der Tests stellt sicher, dass man die Tests mit wenig Aufwand immer wieder ausführen kann. So kann sichergestellt werden, dass bei der Weiterentwicklung des Systems keine unerwünschten Seiteneffekte auftreten. (Refactoring spielt natürlich auch eine wichtige Rolle beim testgetriebenen Vorgehen.)

Tammo unterscheidet zwischen Unittests, die Entwickler schreiben und Akzeptanztests, die Kunden schreiben. Beide Testarten müssen automatisiert werden. Die Akzeptanztests müssen am Anfang i.d.R. von den Entwicklern geschrieben werden. Schrittweise versuchen die Entwickler dann, die Kunden immer stärker einzubeziehen, so dass die Kunden die Tests schließlich selbst schreiben.

Unittests werden mit JUnit (für Java) und die Akzeptanztests mit FIT erstellt. Bei FIT werden die Tests als HTML-Tabellen beschrieben. Die Tabellen kann man in einem Wiki erstellen. Die meisten Kunden bevorzugen aber Word. Neben Java unterstützt FIT eine Reihe weiterer Programmiersprachen.

Jetzt geht Tammo genauer auf Akzeptanztests mit FIT ein. Er stellt die Column-Fixture, die Action-Fixture und die Row-Fixture vor. Column-Fixtures definieren eine Reihe von Eingabewerten, rufen eine Systemfunktion auf und prüfen, ob der Rückgabewert stimmt. Action-Fxutures verfolgen einen eher einen Flow-Ansatz: Man füllt mit Einzelbefehlen Felder, startet Systemfunktionen und prüft Feldwerte. Die Row-Fixture ist geeignet, wenn man eine Menge von Daten prüfen möchte. Und dann gibt es noch die Möglichkeit, sich eigene Fixtures zu definieren, wenn keine der vorhandenen Fixtures passt. Für das Schreiben eigener Fixtures bietet FIT ein Framework, mit dem man leicht HTML-Tabellen parsen und beschrieben kann.

Im Power-Workshop werden nur Column-Fixtures verwendet. Das erste Beispiel ist der obligatorische Taschenrechner. Der Test ist da, läuft aber nicht durch. Die Aufgabe besteht darin, die Tests zum Laufen zu bekommen. Das ist natürlich viel schwieriger als gedacht :-) Das ist aber auch einer der anvisierten Lerneffekte: Akzeptanztests helfen beim Entwurf der Software wenig. Dazu sind sie zu grobgranular.