Testen ist naturgemäß ein wichtiger Aspekt in der Softwareentwicklung. Das gilt zum einen für Unit-Tests auf Modulebene, für die es mit z.B. JUnit gut geeignete Frameworks gibt. Aber genauso wichtig sind Integrations- oder Fachbereichstests, die nicht einzelne Module oder Services, sondern ganze Prozesse testen. Bei solchen Tests ist der Aufwand für Testdatenbereitstellung und Testdurchführung meist um einiges höher.
Besonders wichtig sind wiederholbare Tests in agilen Projekten, die z.B. mit Scrum durchgeführt werden. Ein Grundprinzip bei agilen Projekten sind kurze Releasezyklen, um häufig lauffähige Artefakte an den Product Owner übergeben zu können. Dadurch wird die Transparenz und letzlich auch die Qualität der Ergebnisse erhöht, denn der Product Owner hat die Möglichkeit, durch häufiges Feedback über die ganze Projektlaufzeit direkt Einfluss zu nehmen.
Deswegen ist es gerade bei agilen Projekten wichtig, den Testaufwand überschaubar zu halten. Das lässt sich in dem Maße nur durch automatisierte Tests gewährleisten. Dazu kommt, dass Tests, die dem Product Owner die Möglichkeit geben, Sprint-Ergebnisse zu prüfen und freizugeben, im Idealfall durch den Fachbereich selbst durchführbar sein oder mindestens inhaltlich vorgegeben werden sollten. Denn nur der Fachbereich besitzt häufig das nötige, tiefe geschäftliche Know-how, um umfassende Testfälle zu definieren und die Testergebnisse zu beurteilen. Testen geschieht also besonders in agilen Projekten Hand in Hand durch IT und Fachbereich: Die IT stellt die technische Grundlage für die Tests bereit, die der Fachbereich dann mit Leben füllt.
Genau für solche Szenarien bietet das Framework for Integrated Test (FIT) die nötige – und als Open-Source-Framework auch noch kostenlose – Grundlage. Der große Vorteil: FIT arbeitet tabellenbasiert. Es werden Tabellen aus HTML-Dateien gelesen, die beispielsweise mit Office-Produkten wie Microsoft Word oder Excel erzeugt werden können. Für die Definition der Testfälle ist also kein besonderes, IT-spezifisches Know-how erforderlich. Dadurch kann dieser Schritt problemlos durch den Fachbereich erledigt werden. Die einzelnen Testfälle werden einfach in Tabellenzeilen angegeben, die Spalten definieren die für den Testfall relevanten Daten sowie die erwarteten Ergebnisse.
Der Entwickler muss dann ein Fixture ausprogrammieren, das den eigentlichen Test durchführt. Das Fixture liest die Daten aus den Testfall-Tabellen, führt die zu testende Operation aus und vergleicht die Ergebnisse mit der in der Tabelle vorgegeben Erwartungshaltung.
Das folgende Beispiel zeigt ein Fixture, dass die Konzertsuche der Ticket2Rock-Beispielapplikation testet:
package de.ejb3buch.ticket2rock.session.FIT;
import java.text.SimpleDateFormat;
import java.util.List;
import de.ejb3buch.ticket2rock.EmbeddedContainerTestHelper;
import de.ejb3buch.ticket2rock.entity.Konzert;
import de.ejb3buch.ticket2rock.session.AuskunftLocal;
import fit.ColumnFixture;
public class AuskunftFIT extends ColumnFixture {
public String ort;
public String vonDatum;
public String bisDatum;
public String sucheKonzerte() throws Exception {
EmbeddedContainerTestHelper.startupEmbeddedContainer(null);
try {
AuskunftLocal auskunft = (AuskunftLocal) EmbeddedContainerTestHelper
.lookup("AuskunftBean/local");
SimpleDateFormat dateFormat = new SimpleDateFormat("dd.MM.yyyy");
List<Konzert> konzerte = auskunft
.sucheKonzerte(
ort.equals("null") ? null : ort,
vonDatum.equals("null") ? null : dateFormat
.parse(vonDatum),
bisDatum.equals("null") ? null : dateFormat
.parse(bisDatum));
String result = "";
for (Konzert konzert : konzerte) {
result += konzert.getId() + ",";
}
if (!result.isEmpty()) {
result = result.substring(0, result.length() - 1);
} else {
result = null;
}
return result;
} finally {
EmbeddedContainerTestHelper.shutdownEmbeddedContainer();
}
}
}
Stimmt das Ergebnis mit der Erwartungshaltung überein, so färbt FIT die entsprechenden Zellen grün ein. Weicht das Ergebnis ab, so wird die Zelle rot und FIT schreibt den tatsächlichen Ergebniswert in die Tabelle:
Fehlen Ergebnisse ganz oder sind unerwartete Ergebnisse aufgetreten, wird das auf ähnliche Art ausgegeben. Auf diese Weise kann der Tester sofort sehen, an welchen Stellen der Erwartungshaltung nicht entsprochen wurde.
Ein weiterer Vorteil von FIT ist die Erweiterbarkeit. Gerade bei komplexen Architekturen und Prozessen stößt die Möglichkeit, Testdaten direkt im Fixture vorzugeben, schnell an seine Grenzen, wenn z.B. zu testende Services bestimmte Datenkonstellationen in einer Datenbank benötigen. Während sich das bei z.B. JUnit elegant mit Mock-Objekten lösen lässt, bietet FIT hier von Haus aus keine Lösung. Aber es lässt sich leicht erweitern, beispielsweise um eigene Fixture-Typen, die vor der eigentlichen Testausführung Daten in einer Datenbank persistieren und danach wieder löschen. Diese Testdaten können ebenso einfach in Tabellenform durch den Fachbereich definiert werden. So lassen sich auch komplexe Prozesse testen, ohne die Komplexität der Tests dramatisch zu erhöhen. Der Aufwand für die Erweiterung des Frameworks sollte bei komplexeren Testszenarien aber eingeplant werden.
Auf der der Homepage des FIT-Projekts findet man schon fertige Erweiterungen, wie z.B. FitNesse, das für die Erstellung der Testfälle statt auf Word oder Excel auf eine Wiki-Umgebung setzt, um die Zusammenarbeit zwischen IT und Fachbereich noch zu verbessern. Ebenso verfügbar sind Plugins für gängige Build-Tools wie Maven oder Ant. So lassen sich FIT-Tests bei jedem build automatisch ausführen.
FIT bietet als Framework eine gute Basis für automatisierte Tests, die über den reinen Unit-Test hinausgehen. Mit Hilfe von FIT werden Tests wiederholbar und der Testaufwand wird reduziert. Besonders schön ist es, dass der Fachbereich bei der Testfallerstellung einfach einbezogen werden kann. Das reduziert nicht nur den Testaufwand für das agil und in kurzen Iterationen arbeitende Projektteam, sondern schafft auch ein gemeinsames Verständnis bei IT und Fachbereich. Nicht zuletzt hilft es dem Product Owner, Sprint-Ergebnisse zu beurteilen und damit die Qualität der Software zu verbessern.
