Wer kennt diesen Ablauf nicht: In einem Workshop mit dem Kunden werden Anforderungen gesammelt; das Team erstellt den (mehr oder minder) perfekten Quellcode, der alle Anforderungen umsetzt, und präsentiert die Lösung stolz dem Kunden, der entgegnet: "Großartiges Ding, aber eigentlich dachten wir ..." Wurzel des Übels ist, dass die natürliche Sprache, mit der Anforderungen formuliert werden, immer Raum für Zweideutigkeiten und versteckte Unschlüssigkeiten lässt, selbst wenn die Formulierungen noch so ausgefuchst sind. Die Diskrepanz zwischen dem, was die einen sagen, die anderen verstehen und die einen meinen, dass die anderen verstanden haben, ist oft sehr groß - dies lässt viele Projekte scheitern. Doch wohin führt der Weg, Anforderungen ein wenig formaler zu dokumentieren?
Was für den Entwickler sein "Boxes and Line"-Diagramm ist, das sind für die Vertreter des Fachbereichs ihre vorzüglich in Excel gestalteten Tabellen. Warum sollte man also nicht den Fachbereich die Kriterien, nach denen er die Umsetzung einer Anforderung wirklich akzeptiert (den so genannten Akzeptanztest) in Tabellenform hinterlegen lassen - also seine Sprache sprechen? Als angenehmer Nebeneffekt könnte dabei auch eine Selbstregulierung der Anforderungsflut aufkommen: Der Fordernde hat nun auch Aufwand, eine Anforderung zu definieren, und muss sich stärker mit dem Innenleben einer Anforderung auseinander setzen bzw. damit, wie sinnvoll (bzw. sinnfrei) eine Anforderung ist.

 

Fit: Building the Right Code

Genau an diesem Punkt setzt Fit [1] mit seinem Partner FitNessse [2] an. Fit ist der eigentliche Kern: ein Framework zur Entwicklung von Akzeptanztests. Ausgehend von einer Anforderungsbeschreibung (ruhig auch in Prosa) wird in tabellarischer Form ein Akzeptanztest dazu hinterlegt (Abb. 1). Akzeptanztests sind sowohl Fallnetz als auch Zielbeschreibung eines Entwicklungsprojekts: Nach einem Refactoring oder einer Erweiterung sichern sie die bereits erreichte Funktionalität und zeigen auf, welche zusätzliche Funktionalität der Kunde noch vom System erwartet. Die Kennzahl RTF (Running, Tested Features) gilt als eine der aussagekräftigsten über den Projektfortschritt in einem Softwareprojekt überhaupt.

Die Testtablen samt erläuternder Prosa müssen im HTML-Format oder als Excel-Sheet vorliegen, damit Fit in Aktion treten kann. Fit führt die Testtablen aus und markiert Zellen, die im Testlauf gescheitert sind (Abb. 2).
Als Klebstoff zwischen dem in Tabellen gepressten Akzeptanztest und der eigentlichen Anwendung dienen „Fixtures“ - die Adaptoren zwischen den Testtablen und dem Anwendungscode. Sie interpretieren die Tabellendaten und bestimmen damit den Testlauf gegen die Anwendung (Abb. 1). Fixtures sind somit die Mittler zwischen den von Analysten erzeugten (und evtl. von den Entwicklern in eine geordnete Form gebrachten) tabellarischen Akzeptanztests und dem Anwendungscode.

JUnit: Building the Code Right

Nun stellt sich natürlich die Frage, inwiefern sich Fit und JUnit voneinander abgrenzen. Obwohl sich JUnit mitsamt seinen Satelliten-Frameworks mittlerweile für alle Testebenen berufen fühlt, ist es dennoch im Feld der Unit- und Komponententests zu Hause. Diese Testarten sichern die Robustheit des Codes von innen. Sie sind von Entwicklern für Entwickler geschrieben, um sich mit einem grünen Balken gegen das manchmal drückende schlechte Gewissen abzusichern. Fit zieht, wie schon beschrieben, den Kunden mit in den Testprozess ein und wird damit zum kongenialen Partner von JUnit. Im Gegensatz zu JUnit-Whitebox-Tests ist ein Fit-Test ein Blackbox-Test: Er kennt nur die Außensicht des Systems. Fit-Tests sind von Analysten für Entwickler geschrieben. Zielgruppe an Testlingen sind bei Fit somit Anwendungsfälle und Anwendungsfunktionen - keine Rede von Klassen und Komponenten. Dabei spielt Fit gegenüber JUnit besonders dann seine Vorteile aus, wenn die Testdaten entweder noch nicht klar oder recht umfangreich sind.

Hello Fit

Im Praxiseinsatz wählt man bei Fit oft, und zu Recht, ein Top-down-Vorgehen: Zunächst werden Akzeptanztests in Tabellenform entworfen, dann Fixtures dafür entwickelt und diese gegen die Anwendungsschnittstellen implementiert. Dabei kann ein Akzeptanztest aus mehreren unterschiedlichen Tabellen bestehen, die gemeinsam ein Testszenario beschreiben (Listing 5). Die zu den Tabellen gehörigen Fixture-Klassen müssen in Fit dabei immer von der Klasse fit.Fixture erben, um von Fit ausgeführt werden zu können. Da sich Fit ein Framework nennt, bietet es dementsprechend schon einige vorgefertigte und alltagstaugliche Fixture-Implementierungen (Abb. 3):

• ColumnFixture (Listing 1 und 2): Überprüfung von Berechnungen und Algorithmen durch zeilenweise Überprüfung von Testdatensätzen (Eingaben samt erwarteter Ausgaben).
• ActionFixture, TimedActionFixture (Listing 3 und 4): Test von Zustandsmaschinen durch Auslösen von Zustandsübergängen (press, enter) und Zustandsüberprüfung (check). Eine TimedActionFixture erweitert die ActionFixture um eine Zeitmessung der einzelnen Aktionen. Die Zeitmessung wird mit in der Ergebnistabelle ausgegeben.
• RowFixture (Listing 5 und 6): Überprüfung von Ausgabelisten. Diese Fixture-Art macht oft nur zusammen mit einer ColumnFixture oder ActionFixture Sinn.

Diese mitgelieferten Fixtures können entweder durch eigene Fixture-Klassen erweitert (im Fall der ColumnFixture und RowFixture) oder direkt genutzt werden (im Fall der ActionFixture und TimedActionFixture). Eine genaue Beschreibung der Konventionen, die bei der Erstellung von Testtablen und Fixtures gelten, ist dem Kasten "Fit-Konventionen" zu entnehmen. Die FitLibrary
[3] enthält weitere sehr interessante vorgefertigte Fixtures (hervorzuheben sind die DoFixture, ImageFixture, SetFixture und SetUpFixture), deren Beschreibung aber den Rahmen dieses Artikels sprengen würde. Listing 1

1. Fit-Tabelle - FitNesse-Code
3. |de.qaware.research.fitnesse.StringFormatFixture|
4. |in|capitalizeWord()|
5. |Hat der alte Hexenmeister sich doch einmal wegbegeben!|Hat Der Alte Hexenmeister Sich Doch Einmal Wegbegeben!|
6. |Und nun sollen seine Geister auch nach meinem Willen leben.|Und Nun Sollen Seine Geister Auch Nach Meinem Willen Leben.|
7. |Seine Wort' und Werke merkt ich und den Brauch, und mit Geistesstärke tu ich Wunder auch|Seine Wort' Und Werke Merkt Ich Und Den Brauch, Und Mit Geistesstärke Tu Ich Wunder Auch|

Listing 2

1. ColumnFixture (StringFormat)
3. public class StringFormatFixture extends ColumnFixture {
5. public String in;
7. public String capitalizeWord(){
8. return StringFormat.capitalizeString(in);
9. }
11. }

Listing 3

1. FitNesse-Code
3. |fit.TimedActionFixture|
4. |start|de.qaware.research.fitnesse.CalculatorFixture|
5. |enter|calculator|7|
6. |press|plus|
7. |enter|calculator|5|
8. |press|equals|
9. |check|calculator|12|

Listing 4

1. Fixture (Calculator)
3. public class CalculatorFixture extends Fixture {
5. private RealCalculator calculator = new RealCalculator();
8. // button
9. public void plus() {
10. calculator.plus();
11. }
13. public void equals() {
14. calculator.equals();
15. }
17. // check
18. public int calculator() {
19. return calculator.getValue();
20. }
23. // enter
24. public void calculator(int c) {
25. calculator.enterValue(c);
26. }
27. }

Listing 5

1. FitNesse-Code
3. '''Anforderung: Kunden müssen angelegt werden können.'''
4. Ein Kunde wird repräsentiert durch seinen Namen und seine Adresse (Straße + Nr., Ort und PLZ)
6. |de.qaware.research.fitnesse.CustomerCreateFixture|
7. |name|road|town|zip|createCustomer()|
8. |Testman|Road to Nowhere 99|Middle of Nowhere|CA 90045|true|
9. |Hans Dampf|Alle Gassen 1|München|D-81737|true|
10. |Mon Monsieur|Allée les Chèvrefeuilles 5|Une Ville|F-30400|true|
12. '''Anforderung: Alle bereits angelegten Kunden müssen ausgelesen werden können.'''
14. |de.qaware.research.fitnesse.CustomerReadFixture|
15. |name|road|town|zip|
16. |Testman|Road to Nowhere 99|Middle of Nowhere|CA 90045|
17. |Hans Dampf|Alle Gassen 1|München|D-81737|
18. |Mon Monsieur|Allée les Chèvrefeuilles 5|Une Ville|F-30400|

Listing 6

1. Beispiel-Test des CustomerManager (Fixtures)
3. //Erzeugt Kunden
4. public class CustomerCreateFixture extends ColumnFixture {
5. public String name;
6. public String road;
7. public String town;
8. public String zip;
10. private CustomerManager cm;
12. public CustomerCreateFixture(){
13. cm = CustomerApplication.getInstance().getCustomerManager();
14. }
16. public boolean createCustomer(){
17. //an Anwendungscode delegieren
18. Customer cust = cm.createCustomer(name, road, town, zip);
19. return cust != null;
20. }
21. }
23. //Liest alle Kunden aus
24. public class CustomerReadFixture extends RowFixture {
26. public Object[] query() throws Exception {
27. //an Anwendungscode delegieren
28. Collection customers = CustomerApplication.getInstance()
29. .getCustomerManager()
30. .getCustomers();
31. Collection result = new ArrayList();
32. //Domänenobjekte in für die Fixture ausgelegten Werttypen transformieren
33. for (Iterator it = customers.iterator(); it.hasNext();){
34. Customer customer = (Customer)it.next();
35. result.add(
36. new CustomerVO( customer.getName(), customer.getRoad(),
37. customer.getTown(), customer.getZip() )
38. );
39. }
40. return result.toArray();
41. }
43. public Class getTargetClass() {
44. return CustomerVO.class;
45. }
47. public static class CustomerVO {
49. public String name;
50. public String road;
51. public String town;
52. public String zip;
54. public CustomerVO(String name, String road, String town, String zip) {
55. this.name = name;
56. this.road = road;
57. this.town = town;
58. this.zip = zip;
59. }
60. }
61. }

Listing 7

1. FitNesse Testsuite
3. |FitForFun.TestCalculator|''Testet einen Taschenrechner''|
4. |FitForFun.TestStringFormat|''Testet eine Funktion zur Stringformatierung''|
5. |FitForFun.TestCustomer|''Testet eine einfache Kundenkomponente''|
7. !path classes
8. !path lib/fitnesse/fitnesse.jar
9. !path lib/fit/fit.jar

Fit-Konventionen

Konventionen der Tabellenstruktur
Eine Testtable muss als erstes Feld immer den voll qualifizierten Klassennamen der Fixture enthalten, die den folgenden Tabelleninhalt interpretieren soll. Die Konvention für den weiteren Aufbau einer Tabelle bestimmt die jeweilige Fixture.

Konventionen der vorgefertigten Fixtures

• ColumnFixture
  Tabelle: Eine Spalte der Tabelle entspricht einem bestimmten Eingabe- bzw. Ausgabeparameter. Eine Zeile ist somit ein Testdatensatz, wobei in der ersten Tabellenzeile die Parameter benannt werden müssen. Ausgaben werden von Eingaben dadurch unterschieden, dass nach ihrem Namen "()" angehängt wird. Wird bei einer Zeile erwartet, dass die Eingaben eine Ausnahme verursachen, so muss in der Ausgabespalte das Schlüsselwort error angegeben werden.
  Fixture-Implementierung: Die konkrete Fixture muss fit.ColumnFixture erweitern. Für alle in der entsprechenden Tabelle definierten Eingaben muss ein gleich benanntes öffentliches Attribut in der Klasse vorhanden sein (Listing 2: in). Für die Ausgaben muss eine entsprechend benannte öffentliche Methode in der Fixture bereitstehen.
• ActionFixture
  Tabelle: Die Tabelle benötigt keinen Tabellenkopf (neben der Angabe fit.ActionFixture). Jede Zeile repräsentiert eine Aktion und enthält zwei bis drei Spalten. Die erste Spalte entspricht dabei immer einem der folgenden Kommandos.
  - start: Eine Actor-Fixture wird gestartet. Auf sie beziehen sich alle darauf folgenden Anweisungen. Die ActionFixture kann mehrere Fixtures in einer Testtabelle starten.
  - enter: Der in der dritten Spalte angegebene Wert wird dem Identifier aus Spalte 2 zugewiesen.
  - press: Ein Zustandsübergang wird durch Drücken eines virtuellen Buttons (im Prinzip eine Methode) mit dem Namen aus Spalte 2 ausgelöst.
  - check: Es wird geprüft, ob der Identifier aus Spalte 2 den in Spalte 3 angegebene Wert repräsentiert.
  Fixture-Implementierung: Wird die ActionFixture verwendet, so muss man nur die Actor-Fixtures implementieren. Hierzu muss man lediglich die Klasse Fixture um einen Satz an Methoden erweitern, die die in der Testtabelle angelegten Aktionen repräsentieren. Für die einzelnen Kommandos gelten dabei unterschiedliche Konventionen: Für das enter-Kommando muss eine entsprechend dem in der Tabelle angegeben Identifier benannte öffentliche Methode mit einem Parameter und dem Rückgabewert void implementiert werden. Für das check-Kommando gilt die umgekehrte Regel: kein Parameter und ein Rückgabewert. Dem press-Kommando genügt eine entsprechend benannte Methode ohne Parameter und Rückgabewert.
• RowFixture
  Tabelle: Die Tabelle repräsentiert eine erwartete Ergebnisliste. Eine Zeile der Tabelle entspricht somit einem Datensatz in der Ergebnisliste. Der Tabellenkopf besteht aus den Namen der jeweiligen Datensatzattribute. Die Tabelle fordert, dass die Ergebnisliste mindestens die angegebenen Datensätze enthält. Spielt die Ordnung der Datensätze eine Rolle, so kann eine zusätzliche Spalte mit dem Titel order eingeführt werden, in dem die geforderte Position in der Ergebnisliste angegeben werden kann.
  Fixture-Implementierung: fit.RowFixture ist die Basisklasse, die diese Fixtures erweitern müssen. Die Basisklasse ist abstrakt und fordert auf, die Methoden void query():Object[] und getTargetClass():Class zu implementieren. Die query()-Funktion soll dabei die zu prüfende Ergebnisliste zurückgeben und getTargetClass() gibt dem Fit-Testrunner die Information, welchen Typ die einzelnen Elemente der Ergebnisliste haben. Von diesem Typ fordert Fit, dass alle Attribute, die in der Tabelle verwendet werden, als öffentliche Felder vorliegen müssen. Aus diesem Grund ist es oft notwendig, eine Zwischenrepräsentation eines Domänenobjekts anzulegen (Listing 6), wie man es schon vom Datenaustausch zwischen der Präsentationsschicht und der Anwendungslogik in Form der Value Objects kennt.

FitNesse, das fitte Frontend

 
Fit allein bietet keine Unterstützung bei der Erstellung der Testtablen. Man ist auf Excel oder einen HTML-Editor angewiesen, wie z.B. Dreamweaver (oder das ganz ordinäre Word). Da der Fit-Erfinder Ward Cunningham gleichzeitig Urheber des Wiki ist, liegt es natürlich nahe, Fit mit einem Wiki zu kombinieren, um die Akzeptanztests unkompliziert per Webbrowser pflegen zu können. Genau dafür dient FitNesse. Fit-Tests werden in FitNesse als Wiki-Seiten hinterlegt und können direkt innerhalb des Wiki ausgeführt werden. Abpictureung 4 zeigt das Zusammenspiel von Fit und FitNesse. Die Installation von FitNesse ist narrensicher: Ein Webserver wird mitgeliefert. Einfach das Archiv entpacken und run.bat starten. Eventuell muss dabei noch der Port, an dem der FitNesse-Webserver lauscht, per -p-Parameter verändert werden. Die Bedienung des Wiki ist, entsprechend der Zielgruppe, intuitiv. Alle möglichen Aktionen sind über die Leiste am linken Seitenrand zugänglich. Per Edit können die aktuelle Seite bearbeitet und ein neuer Akzeptanztest definiert werden. Die dabei zu verwendende Notation kann den Listings 1, 3 und 5 sowie einer allgemeinen Übersicht der Abpictureung 4 entnommen werden. Über Test werden die auf der aktuellen Wiki-Seite definierten Testtablen ausgeführt. Damit das funktioniert, müssen drei Dinge erledigt werden:

• In den Properties die aktuelle Wiki-Seite als Test markieren.
• Auf der Wiki-Seite den Java-Classpath angeben, über den alle auf der Seite verwendeten Fixtures und die Fit- und FitNesse-Klassen zugänglich sind. Dies geschieht über das Wiki-Markup !path. Sind die Pfadangaben relativ, so beziehen sie sich auf das Ausführungsverzeichnis von run.bat.
• Alle "?" hinter Klassennamen dadurch eliminieren, dass ein Inhalt (kann auch eine leere Wiki-Seite sein) hinterlegt wird. FitNesse interpretiert die CamelCase-Notation der Klassen als Wiki-Link und würde ohne eine dahinter liegenden Seite dem Fit-Testrunner den Klassennamen mitsamt dem "?" übergeben. Die Aktion RecentChanges ist recht hilfreich, sich als Entwickler eine Übersicht darüber zu verschaffen, wo die aktuellen Hotspots der Analysten sind und wo Bedarf besteht, ein Fixture anzupassen bzw. zu entwickeln.

 

Fazit

Das Anforderungsmanagement fordert von seinen produzierten Anforderungen, dass sie komplett, präzise und deterministisch sind. All diese Punkte kann man durch den Einsatz von Fit positiv beeinflussen: Die Anforderung werden kompletter, da es nun Aufgabe des Kunden ist, zu allen Anforderungen entsprechende Akzeptanztests zu definieren. Die Anforderungen werden präziser, da sie frühzeitig an Beispielen geklärt werden können. Die Anforderungen werden deterministischer, da Fit-Tests entweder erfolgreich oder nicht erfolgreich sein können. All diese Punkte stärken das Vertrauen des Kunden in die Software. Besonders im Zusammenwirken mit einem Bug-Tracking-System, wie z.B. dem ebenfalls Wiki-basierten Trac [7], kann FitNesse seine Stärke als Fallnetz der SW-Entwicklung ausspielen - Links auf Bugs können direkt neben dem Akzeptanztest platziert werden. Durch die Verfolgung der Tabellen hin zu den Fixtures und hin zum Anwendungscode ist eine Zuordnung einer Anforderung zum Code, der sie umsetzt, einfach möglich.
Auch im Zusammenhang mit dem Softwaredesign sind positive Nebeneffekte zu vermelden. Alle Codeteile, die durch Fixtures geprüft werden, müssen entweder eine schmale, dienstorientierte Schnittstelle anbieten oder das entsprechende Fixture erfordert hohen Implementierungsaufwand. Der Leidensdruck ist dann oft so groß, dass man die Fixture-Forderungen schon beim Design der Schnittstellen berücksichtigt. Damit werden implizit lose Kopplung und dienstorientierte Schnittstellen gefördert - an Schichtengrenzen (und dort testet Fit) ein sehr gefragter Architekturstil.
So viel zum Licht. Es können aber auch Schatten ausgemacht werden. So fehlen Plug-ins für Entwicklungsumgebungen, die bei der Entwicklung von Fit-Tests unterstützen und den Testlauf samt ihrer Resultate enger einbinden. Für das Build-Tool Maven ist ein FitNesse-Plug-in verfügbar [8], mit dem die Akzeptanztests in den täglichen Build eingebunden werden können. Für Ant steht ein Fit-Plug-in zum Download bereit [9]. Eine letzte Info für Java-Fremdgänger: Fit (und teilweise auch eine FitNesse-Anbindung) sind auch für .NET, C++, Delphi, Lisp, Objective C, Python, Ruby, Smalltalk und Perl verfügbar.
Josef Adersberger (Josef.Adersberger@QAware.de) ist Leiter des Bereichs Improvement & Innovation bei QAware und Dozent an der Fachhochschule Rosenheim. Sein Hauptinteresse gilt der Software-Qualitätssicherung, der technologieübergreifenden Softwarearchitektur und -produktionsumgebungen.

Links & Literatur

• [1] Fit-Framework: fit.c2.com
• [2] FitNesse: www.fitnesse.org
• [3] FitLibrary User-Guide: fitnesse.org/FitNesse.FitLibraryUserGuide
• [4] FitNesse Markup-Referenz: fitnesse.org/FitNesse.MarkupLanguageReference
• [5] Frank Westphal: Testgetriebene Entwicklung mit JUnit & Fit, dpunkt, 2005
• [6] Rick Mugridge, Ward Cunningham: Fit for Developing Software, Prentice Hall, 2005
• [7] Trac: www.edgewall.com/trac/
• [8] Maven FitNesse Plug-in: fitnesse.org/PluginsPage.MavenPlugIn
• [9] AntFit: www.cmdev.com/antfit/