Homepage: http://fit.c2.com/
siehe auch meine Veröffentlichungen

Mit FIT werden Akzeptanztests abgebildet. Akzeotanztests sind Black-Box-Tests, die vom Auftraggeber bereits während der Anforderungsanalyse und -spezifikation formuliert werden können.

Bild aus Frank Westphals Buch - S. 251

Mit einem Akzeptanztest wird eine grössere Komponente getestet, die aus dem Zusammenspiel mehrerer Entitäten besteht. Unit-Tests hingegen testen kleinere, einzelne Komponenten, nicht deren Integration. Man kann sagen:

FIT-Tests prüfen, ob man das Richtige implementiert
Unit-Tests prüfen, ob das Implementierte richtig ist

Mit 1. prüft man natürlich auch in gewisser Weise das 2.

Überblick:

Aus Sicht der Fachseite

Über Excel oder Word wird ein Datenblatt designt, in das der Tester seine Input-Werte und die erwarteten Output-Werte einträgt (hier kann auch erläuternder Text dabei sein). Über den Spaltennamen (zumindest bei ColumnFixture) werden die Attribute und die aufzurufenden Methoden identifiziert.

Durch die Verwendung von Office-Dokumenten zur Spezifikation der Eingabewerte und der erwarteten Ausgabewerte ist eine gute Basis für eine hohe Akzeptanz bei der Fachseite (dem Auftraggeber) geschaffen, da hier i. a. eine grosse Affinität zu Office-Produkten vorhanden ist. Andere Techniken wie beispielsweise SGML-Dokumente oder Textdateien hätten hinsichtlich der Akzeptanz grössere Schwierigkeiten. Ausserdem lässt sich um die Nettodaten Text schreiben, so dass sich die Akzeptanztests prima in das Fachkonzept integrieren lassen.

Was Akzeptanztests im Fachkonzept - in den fachlichen Anforderungen also - integrieren???

Wenn man es genau nimmt, handelt es sich bei den FIT-Tests weniger um Tests als um eine Beschreibung der Anforderungen auf sehr konkretem Niveau. Für die Black-Box, die es zu implementieren gilt, werdden die ergebnistreibenden Parameter identifiziert und die erwarteten Ergebnisse beschrieben. Dies ist eine andere Sichtweise auf Anforderungen, aber es handelt sich nichtsdestotrotz um Anforderungen.

Aus Sicht des Entwicklers

Aus Excel und Word wird dann eine HTML-Datei erzeugt (Speichern unter) und dann kann der Test über die Console folgendermassen gestartet werden:

java -classpath fit.jar fit.FileRunner examples/input/arithmetic.html results.html

Ergebnis ist wiederum eine HTML-Datei (hier: results.html), in der die Erfolge/Misserfolge farblich (grün, rot, gelb) hervorgehoben sind.

Aus Sicht des Managements

Für das Management ist die Feststellung des Projektfortschritts i. a. sehr wichtig. FIT trägt dem durch Ausgabe einer Statistik Rechnung. Unserer Erfahrung nach ist das ein wichtiges Kriterium für die Akzeptanz seitens des Managements (in unserem Fall wurde die Statistik mehrmals täglich abgefragt). Es ermöglichte eine wesentlich bessere Risikoeinschätzung und hatte positive Auswirkungen auf die Planbarkeit vonn Releases.

Startschwierigkeiten

Problem 0

Ich versuche die Daten per "Datei - Speichern unter" als HTML zu speichern. Dabei gebe ich an, dass die "Gesamte Arbeitsmappe" gespeichert werden soll. Funktioniert prima, aber meine erzeugte HTML-Datei enthält die Testzeilen nicht :-(((

Lösung: man darf nicht "Gesamte Arbeitsmappe" angeben, sondern den Zellbereich markieren (in dem sich relevante Daten befinden) und dann die Option "Auswahl: Tabelle" verwenden.

Problem 0.5:

Das von Excel erzeugte HTML ist total unübersichtlich und enthält viele Skripte und Formatierungsanweisungen. Hier ein Beispiel: 872361.

Ausserdem enthält die erste Spalte der ersten Zeile der Tabelle nicht den Namen der Fixture, was zu folgender Exception führt:

java.lang.RuntimeException: The fixture "" was not found

at fit.Fixture.loadFixture

Hieraus kann man auch ableiten, dass die erste Spalte der ersten Zeile den Namen der Fixture enthalten muss (nicht unbedingt in Excel, aber im HTML - man hat weniger Arbeit, wenn das auch im Excel-File so ist).

Problem 0.6:

Im Internet Explorer werden die Fehlermdlungen und Exceptions nicht im erzeugten HTML-Output dargestellt. Im Firefox funktionierts.

Problem 1

Mit einem HTML-Export aus "MS Windows Word" hatte ich keine Probleme, den FileRunner zum Laufen zu bringen. Anders hingegen mit einer HTML-Export aus OpenOffice 2.0 heraus. Eine solche Datei konnte nicht geparst werden:

java.text.ParseException: Can't find tag: td

at fit.Parse.findMatchingEndTag(Unknown Source)

Scheinbar erzeugt OpenOffice ein anderes HTML als WinWord, was ein Blick in die erzeugten HTMLs offenbart. OpenOffice erzeugt mit TH-Einträgen für die Überschriften eigentlich das bessere HTML, doch scheinbar ignoriert der Parser TH-Einträge, so dass es zu obiger Fehlermeldung kommt.

Es hilft auch nichts, das HTML-Output-Format (Extras - Optionen - Laden/Speichern - HTML-Kompatibilität) umzustellen (Default: Netscape, weitere Optionen: MS Internet Explorer, HTML 3.2, OpenOffice Writer). Beim Erzeugen einer Tabelle kann man - zumindest über "Tabelle - Einfügen - Tabelle" - angeben, ob eine Überschrift verwendet und auch wiederholt werden soll. Dies beseitigt auch ein paar TH-Einträge, doch der Name der Fixture-Klasse bleibt in TH-Einträgen. Da TH-Einträge vom Parser ignoriert werden, wird keine Name gefunden und FIT weiss somit nicht welche Testfixture-Klasse zu starten ist. Die Fehlermeldung ist dementsprechend: "The fixture "" was not found". In der Klasse ??? sind diese Zellen-Erkennungs-Tags leider hart codiert, so dass keine Chance zur Anpassung besteht, ohne den Code zu ändern. Eine mögliche FIT-Verbesserung?!?

In der Dokumentation steht: "The parser looks for table, tr and td tags ..." und das kann man auch sehr schnell im Code verifizieren (einfach mal den Code des FileRunner.process anschauen).

Lösung: als CSV-Datei exportieren und dann ein selbstgeschriebenes Programm laufen lassen (unser Programm hat den Namen csv2html_2357894.java), das daraus dann HTML macht

Problem 2

Meine ersten Gehversuche waren in Ordnung, ich bekam die einfachsten Beispiele zum Laufen. Mein erster Test im Projekt hat mich allerdings beinahe verzweifeln lassen.

Mein Excel-File:

dreba..prj.ikr.ika.tx.fachseite.KreditartWertelisteTest
kreditartenschluessel	bezeichnung	isValid()
XXXX	zur Löschung vorgesehene Kredite	true
0000	Sonderkondition ohne Limit	true

Leider bekomme ich folgende Fehlermeldung:

kreditartenschluessel

bezeichnung[1]
java.lang.NoSuchFieldException: bezeichnung[1]
at java.lang.Class.getField(Class.java:1005)
at fit.ColumnFixture.bindField(Unknown Source)

isValid()

Mit der Fehlermeldung kann ich nicht so viel anfangen, da meine Klasse dreba.prj.ikr.ika.tx.fachseite.KreditartWertelisteTest folgendermassen aussieht:

public class KreditartWerteliste extends ColumnFixture {

public String kreditartenschluessel;
public String bezeichnung;

}

Tja, nach langer Recherche finde ich raus, dass es an einer Anmerkung (ein komisches Excel-Feature, das die Excel-Profis auf Fachseite gerne nutzen) liegt, die an der Spalte Bezeichnung hängt. Nach Löschung der Anmerkung funzt es prima. :-(((

Fazit: im Bereich der Fehlermeldungen sollte FIT noch etwas tun.

Problem 3

Schlägt ein Test wegen einer Exception fehl (bekommt die Farbe gelb), dann gibt FIT den Stack-Trace aus. Leider wird im Internet Explorer der Stack-Trace nicht angezeigt (wegen des erzeugten HTMLs), wohl aber im Firefox.
Ausserdem werden die erwarteten Results im Internet Explorer nicht angezeigt, im Firefox hingegen schon :-)

Das Problem lässt sich beheben, indem man die Formatierungsanweisungen zu Beginn des HTML-Dokuments entfernt - aber das ist ja nicht wirklich befriedigend, denn wir wollen ja nicht immer das durch den Excel-Export generierte HTML manuell anpassen :-(

Problem 4

In einem zu berechnenden Wert wird im erzeugten Output-HTML nur "error" ausgegeben, obwohl ich aus dieser Methode mit einer Exception rausfliege. Die Exception kommt auch nicht in die am Ende ausgegebene Statistik (0 right, 0 wrong, 0 exceptions).

Nach der Analyse des FIT-Source-Codes kommt diese Meldung immer dann, wenn in einer Zelle eines erwarteteten Ergebniswerts nichts drinsteht und darin eine Exception auftritt. Ein leerer Wert in einer Ergebniszelle führt nämlich dazu, dass der ermittelte Wert ignoriert wird - er fliesst nicht in die Statistik ein, wird nicht mit rot, grün oder geld gekennzeichnet, sondern es wird nur der berechnete Wert in hellgrau dargestellt. (siehe auch Problem 5)
o
Fazit: im Bereich der Fehlermeldungen sollte FIT noch etwas tun.

Problem 5:

Ich erwarte bei einem Ergebnis keinen Wert (die Methode liefert in diesem Fall auch "null") und trage deshalb auch in die Excel-Zelle ein. Doch die Ergebnisse werden nicht mit rot, grün oder gelb bewertet. Ausserdem fliesst das Ergebnis nicht in die Statistik ein.

Ergebniszellen ohne Inhalt führen dazu, dass der berechnete Wert ignoriert wird - eine leere Zelle ist scheinbar kein gültiges erwartetes Ergebnis. Wenn man das trotzdem will, dann sollte man ein anderes Zeichen als Kennzeichnung für "leer" reinsetzen und entsprechende "null"-Ergebnisse der Methode in dieses Zeichen umwandeln (als Zeichen bietet sich "-" an).

Problem 6:

Mit einem sehr grossen Test (mehrere 10.000 Testzeilen, XML-File hat eine Grösse von 5 MB) geht gar nichts mehr - die VM crasht mit einer OutOfMemory-Meldung. Auch wenn man die Max-Heap-Size der VM (-Xmx) auf 1,5 GB hochsetzt.

Eine Analyse des Source-Codes ergibt, dass die Datei zunächst komplett in einen String eingelesen wird - vielleicht liegt darin schon die Beschränkung.

Backstage - Framework-Internas

In diesem Kapitel werfe ich einen Blick in den Source-Code von FIT.

Design - Klassendiagramm:

Design - Sequenzdiagramm:

Codierung:

Auffällig ist, dass beinahe keine Kommentare vorhanden sind (vielleicht ist das auch nur in meinem per Release ausgelieferten Codestand so und ich würde mehr Kommentare sehen, wenn ich die Sourcen vom CVS-Server ziehen würde). Das hat mir das Verständnis der Klasse fit.Parse zunächst sehr schwer gemacht (rekursive Aufrufe). Doch gibt es zu jeder Klasse eine entsprechende Testklasse (ParseTest), die eine Dokumentation sehr gut ersetzt. Die Testklasse hat das Modell hinter der Parse-Klasse sehr schön veranschaulicht.

Erweiterbarkeit:

Im Rahmen eines Kundenprojekts empfanden wir das Arbeiten über den HTML-Export aus Excel heraus als sehr umständlich. Unsere Idee war, das Excel-File über die Apache POI-API direkt auszulesen und auch ein Excel-Ergebnis zu erstellen. Eigentlich wollten wir das Framework so erweitern, daß sich diese Variante nahtlos zu den Alternativen HTML- und Wiki-Verarbeitung integriert. Allerdings war das nicht so einfach möglich, denn beispielsweise werden Ergebnisse (richtig, falsch, Exception) nicht View-unabhängig gekennzeichnet, sondern in der Parse-Klasse schon zum Zeitpunkt der Ergebnisermittlung (nicht erst bei der Ergebnisaufbereitung) als HTML-Code gespeichert (siehe unten).

Wir gaben deshalb irgendwann auf und schrieben einen eigenen FileRunner (Fit4XlsRunner). Darin parsten wir das Excel-File per POI-Api und riefen die entsprechenden Fixtures auf. Da sich diese Lösung nicht nahtlos in das Framework integrierte, mußten wir einige Framework-Funktionalitäten (z. B. Statistiken: Counts, summary) nachimplementieren oder standen uns nicht zur Verfügung (z. B. ActionFixtures - unsere Lösung funktionierte nur mit ColumnFixtures).

Noch ein paar Details:

FIT bietet keinen Framework-Mechanismus, um neue Input-File-Parser in den FileRunner zu integrieren. Dieses Problem hätte man noch leicht durch Ableitung und überschreiben der process-Methode lösen können
während das Parse-Objekt von der Input-Datei und dessen Beschreibungssprache (HTML, Wiki) abstrahiert, ist das bei der Ergebnisaufbereitung leider nicht der Fall. In den Zellen des Parse-Objekts wird in HTML-Syntax gekennzeichnet, ob die Zelle im Ergebnis grün, rot, gelb oder transparent dargestellt wird :-(

public class Fixture {

public void error(Parse cell, String message) {

cell.body = escape(cell.text());
cell.addToBody("<hr><pre>" + escape(message) + "</pre>");
cell.addToTag(" bgcolor=\"" + yellow + "\"");
counts.exceptions++;

}

die Klasse "Fixture" enthält viel HTML-Code, obwohl diese Klasse - aus meiner Sicht - nichts mit der Beschreibungssprache zu tun haben sollte

Zusammenfassung der Erweiterbarkeitsanalyse:

FIT ist - zumindest meiner Analyse zu Folge - relativ schwer erweiterbar (oder ich habe die Philosophie icht richtig verstanden)

Tips

innn Excel lassen sich immer noch am besten Testfälle erfassen, denn die Filtermöglichkeiten, Möglichkeit zur Spaltenausblendung und farbliche Hervorhebungen machen die Editierung grosser Tests wesentlich übersichtlicher es bei einer Pflege in CSV oder im FitNesse-Wiki jemals möglich wäre. Ausserdem ist Excel natürlich die bei Fachseiten bestens akzeptierte Variante. Für interaktive Tests (insbesondere durch die Entwickler während der Entwicklung ist FitNesse sehr hilfreich.
am besten verwendet man den Export nach CSV und erzeugt aus dem CSV dann HTML (wir haben in einem Projekt die Klasse csv2html_2357894.java benutzt). Dann lösen sich die Probleme 0, 0.5, 1, 2, 3.
Es hat sich als nützlich erwiesen eine Spalte TEST_ID einzuführen, die einen eindeutigen Bezeichner des Testfalls enthält. Das macht die Kommunikation zwischen IT (schaut im HTML-Output und hat nicht mehr die Excel-Zeilen-Nummern) und Fachseite (die ja im Excel-Sheet schaut) einfacher. Ausserdem können Entwickler diesen Testfall dann einfacher extrahieren, um den FIT-Test beispielsweise nur mit einer Zeile laufen zu lassen (zwecks Debugging). Um den Identifier nicht manuell vergeben zu müssen, kann man beispielsweise folgende Excel-Formel verwenden, die die Zellbezeichnung ausgibt:

=ADRESSE(ZEILE(A6); SPALTE(A6);4)

Die Reihenfolge der Spalten wird im FIT-Test eingehalten, d. h. wenn man es nicht als Feature nutzen möchte, sollte man die Berechnungsmethoden ans Ende stellen (denn erst dann sind ja alle Input-Werte gefüllt)
Die Input-Werte müssen am Anfang einer neuen Zeile (oder am Ende) zurückgesetzt werden, denn bei einem leeren Eintrag wird das Feld nicht gesetzt (ehrlich - war das so???). Eine Verbesserung im Framework könnte darin bestehen, über eine neue Zeile (und eine neue Tabelle) zu informieren, so dass der Fixture-Entwickler die Chance hat, sich per Einschubmethode einzuklinken (ähnlich wie die setup-Methode im JUnit-Framework).
leere Excel-Zellen als erwarteter Ergebniswert werden ignoriert. Wenn "null" ein gültiges prüfbares Ergebnis einer Methode ist, dann sollte man ein Ersatzsymbol (z. B. "-") für eine "null"-Ergebnis verwenden (siehe oben: Problem 5)
Es ist möglich in einer Excel-Datei mehrere Fixtures abzubilden, d. h. mehrere Tests. Allerdings muss man bei der HTML-Generierung dann selbst Hand anlegen, denn jeder Test muss mit einem <table>-Tag geklammert sein - Excel kann natürlich nicht wissen wann eine neue Fixture beginnt.

Bewertung

Ich habe in einem grossen Projekt bei einer grossen deutschen Bank eingesetzt eine vergleichbare Variante zur Prüfung eines relativ schwierigen Algorithmus verwendet. Allerdings haben wir hierzu eine Java-Applikation gechrieben, die als Testfall-Editor diente. Dies erforderte erstens einen relativ hohen Programmieraufwand (5 Tage) und man konnte keinen erläuternden Text drumherumschreiben. Mit dem FIT-Framework hätten wir mindestens 3 Tage Programmieraufwand gespart und das gleiche erreicht.

Die Fachseite empfand diese Form der Testunterstützung als vorbildlich. Die Entwickler selbst hatten den Vorteil, dass die Fachseite die Testfälle erfasste und ihnen somit einen Grossteil der Entwicklertests abnahm (allein das sparte wieder einen Grossteil der 5 Tage Entwicklungszeit ein - die Fachseite erklärte sich ausserdem bereit die Entwicklungskosten komplett zu bezahlen). Für beide Seiten also ein Gewinn.

Diese Erfahrungen haben wir auch mit FIT beim gleichen Kunden gemacht. Alle Seiten haben ausschliesslich positive Erfahrungen gemacht (bestes Kosten/Nutzen-Verhältnis, das ich jeh kennenlernen durfte) und ich sehe die Chance, dass diese Testfälle bereits zur Anforderungsanalyse spezifiziert werden. Die Fachseite ist jedenfalls ganz heiss, weitere Bereiche durch Fit-Tests abzudecken.

Sicherlich gibt es auch für FIT Grenzen, innerhalb derer sich der EInsatz wirklich lohnt. Aber es ist in jedem Fall ein weiteres Tool im Werkzeugkasten des pragmatischen Programmierers. Jederzeit und immer wieder :-)

Einzig und allein die Bugs im Umfeld Excel-to-HTML stören ein wenig und erhöhen den Einarbeitungsaufwand. Sollten diese Probleme in einer kommenden Version behoben werden, kann ich FIT uneingeschränkt empfehlen.