die Frontpage des FitNesse-Servers enthält eine Liste (oder Tabelle) mit den Verweisen auf die einzelnen Projekt-Gruppen;

 |!c '''List of all Projects using this FitNesse-Instance'''|
 |!c '''Project Name''' | '''Brief Description'''           |
 |!c ProjectGroupHorst  | Horst's Demo-Projects;            | 

Beispiel: so sieht es aus ...

• bis jetzt verändere ich an der Standard-Installation nur wie gezeigt die Frontpage;
• das hat für mich den Vorteil, daß wir die gesamte FitNesse-Dokumentation direkt im Zugriff haben;

die Einstiegsseite einer Projekt-Gruppe zeigt die Liste/Tabelle aller Projekte;
"^" steht als Abkürzung für Sub-Wiki;
zusätzlich werden ein paar projekt-spezifische FitNesse-Variablen definiert;

 !3 List of available Tutorial Projects:
 | '''Tutorial-Name''' |!c '''Description''' |
 | ^ProjectUserStoryList | example to test the TDD tutorial "User Story List";|

 ----
 !****> '''Test-Utilities for whole Project-Group''':
 '''Variables'''
 !define projectGroupName {Horst's}
 !define projectGroupHOME {/home/Horst/06-01-FitNesse-Examples}
 !define COLLAPSE_SETUP {true}
 !define COLLAPSE_TEARDOWN {true} 

Beispiel: so sieht es aus ...

• die wirklich wichtige Variable ist "projectGroupHOME": auf dem Build-Rechner besitzt jede Projekt-Gruppe genau ein Wurzel-Verzeichnis;
• d.h. an genau dieser einen(!) Stelle im FitNesse-Wiki pflege ich diesen Verweis;
• in allen Tiefen der Test-Seiten-Strukturen in FitNesse wird diese Variable verwendet (s.u.);

eine Projekt-Seite zeigt die Liste/Tabelle aller vorhandenen Test-Suites (Sub-Wikis);

 !3 List of Test-Suites:
 | '''Test-Suite''' |!c '''Focus of Tests within Suite''' |
 | '''^SuiteForTestsOnLists'''| check requirements on story lists; |

 !****> '''Test-Utilities for this Project''':
 '''Classpaths'''
 !path ${projectGroupHOME}/userStoryList/fitnesse/*

 '''Variables'''
 !define projectName {User Story List}

 '''Fixtures'''
 !fixture de.franzke.userStoryList.AboutSourceCodeUnderTest
 !fixture de.franzke.userStoryList.StoryListAdministration
 !fixture de.franzke.userStoryList.UserStoryListing

 '''^SetUp'''
 '''^TearDown'''
 ****!  

Beispiel: so sieht es aus ...

• hier sehen wir die Verwendung der Variablen "projectGroupHOME": im Wurzel-Verzeichnis der Projekt-Gruppe gibt es für jedes Projekt (=Produkt) ein eigenes Verzeichnis;
• alles, was FitNesse an Code für die Tests benötigt, findet es im angegebenen Verzeichnis 'fitnesse' des Projects 'userStoryList';
• die Angabe der Fixtures kann den Kunden die Erstellung ihrer Tests mittels Fixture-Wizzard erleichtern; allerdings habe ich festgestellt, daß sich eher bestimmte Szenarien-Muster bilden, die dann einfacher per cut-and-paste wiederverwendet werden;

eine Suite-Seite zeigt die Liste/Tabelle aller vorhandenen Test (Sub-Wikis) zu einem bestimmten Themen-Schwerpunkt im Projekt;

 ----
 !3 List of Tests:
  * ^AddStoriesToTheList
  * ^TestUpdateStoryTitles
  * ^TestRejectOfDuplicateTitle 

Beispiel: so sieht es aus ...

• sind die einzelnen Test-Seiten als sogenannte Sub-Wikis abgelegt, können wir sie alle zusammen als Suite durchlaufen lassen;
• eine Bemerkung zur Namensgebung: die angeführt Seite "AddStoriesToTheList" ist eher ein Negativ-Beispiel: ich pflege im FitNesse-Wiki auch noch reine Informationsseiten und da erleichtert es die Orientierung des Lesers, wenn man Test-Seiten mit "Test" beginnen läßt (und Suites mit "Suite");
• die Namens-Konvention verhindert auch, daß ein Test zwar geschrieben, aber nie ausgeführt wird - weil man vergessen hat, das notwendige Seiten-Property per Hand zu setzen;

Wie wir oben gesehen haben, benötigen wir nur das Verzeichnis 'fitnesse' für den Klassenpfad von FitNesse. Das Verzeichnis liegt auf oberster Ebene im Projekt-Verzeichnis.

 |-/home/Horst/06-01-FitNesse-Examples/userStoryList
 | =================================================
 |   |
  ...
 |   |
 |   |-fitnesse
 |   | ========
 |   |   |-fitlibrary.jar
 |   |   |-fitnesse.jar
 |   |   |-userStoryList-fitnesse-v-1-4-1.jar                   // (1)
 |   |   |-userStoryList-tests-v-1-4-1.jar                      // (2)
 |   |   |-userStoryList-v-1-4-1.jar                            // (3)
 |   |
  ...
 
 

FitNesse erwartet hier den kompletten Code, der für die Tests notwendig ist:

• zu (1): dieses jar-File enthält alle Fixtures;
• zu (2): dieses jar-File enthält alle (JUnit-) Tests; (wird in der Regel nicht bei den FitNesse-Tests benötigt - aber man weiß ja nie ...)
• zu (3): hier ist der eigentliche Domain-Code;
• im "wirklichen Leben" würde man hier sicherlich noch einige Bibliotheken finden, die wir in unserem Projekt verwenden;
• Anmerkung: die Versionsnummer (v-1-4-1) stammt aus dem bei mir verwendeten Build-Prozeß;

Der folgende Ausschnitt zeigt die entscheidenden Aktionen zum Veröffentlichen des notwendigen Codes für FitNesse: (ich gehe hier davon aus, daß der Quellcode aus einem Repository (z.B. CVS) geholt wird)

 <!-- //////////////////////////////////////////////////////////////////// -->
 <!--  Publish Code to FitNesse;                                           -->
 <!-- //////////////////////////////////////////////////////////////////// -->
 <target name="publish.to.fitnesse"
         description="after a clean test-run publish all jar's to fitnesse;"
         depends="_set.standard.properties,                                    // (1)
                  _set.project.properties,                                     // (2)
                  _get.sources,                                                // (3)
                  _compile.and.jar.domain,                                     // (4)
                  _compile.and.jar.junit,                                      // (5)
                  _run.junit,                                                  // (6)
                  _compile.and.jar.fitnesse">                                  // (7)

   <delete dir="${fitnesse.dir}" />                                            // (8)
   <mkdir  dir="${fitnesse.dir}" />

   <copy todir="${fitnesse.dir}">
     <fileset dir="${build.jar.dir}">                                          // (9)
     <include name="**/*.jar"/>
     <exclude name="**/CVS/**/*"/>
   </fileset>
   </copy>

   <echo message="Target 'publish.to.fitnesse' finished OK." />

 </target>

 <!-- //////////////////////////////////////////////////////////////////// -->
 <!--  Compile FitNesse Code and create the jar-file;                      -->
 <!-- //////////////////////////////////////////////////////////////////// -->
 <target name="_compile.and.jar.fitnesse"
         depends="_set.standard.properties,
                  _set.project.properties">

   <javac destdir="${build.fitnesse.dir}">                                     // (10)
     <classpath refid="vendor.lib.path"/>                                      // (11)
     <classpath refid="domain.class.path"/>
     <classpath refid="test.class.path"/>
     <src path="${source.dir}/${project.module}"/>
     <patternset refid="sources.fitnesse"/>
   </javac>

   <jar jarfile="${jar.fitnesse}">                                             // (12)
     <fileset dir="${build.fitnesse.dir}">
       <include name="**/*.class" />
     </fileset>
   </jar>

   <echo message="Target '_compile.and.jar.fitnesse' finished OK." />

 </target>
 

• zu (1) (Target hier nicht gezeigt): ich gehe davon aus, daß für alle Projekte auf dem Build-Rechner ein Satz gemeinsamer Properties verwendet wird;
• zu (2) (Target hier nicht gezeigt): jedes einzelne Projekt setzt noch spezifische Properties; (z.B. das CVS-Repository)
• zu (3) (Target hier nicht gezeigt): die Quellen werden aus dem Repository in den Build-Bereich geholt; (inkl. der notwendigen Bibliotheken)
• zu (4) (Target hier nicht gezeigt): Domain-Code wird übersetzt und ein jar-File wird erzeugt;
• zu (5) (Target hier nicht gezeigt): JUnit-Test-Code wird übersetzt und ein eigenes jar-File wird erzeugt;
• zu (6) (Target hier nicht gezeigt): die JUnit-Tests werden alle ausgeführt;
• zu (7): Fixture-Code wird übersetzt und ein eigenes jar-File wird erzeugt;
• zu (8): ich möchte sicher gehen, daß sich keine Versionen vermischen;
• zu (9): alle jar's wurden im Build-Bereich in diesem Verzeichnis erzeugt;
• zu (10): im Build-Bereich gibt es ein eigenes Verzeichnis für Fixture-Code;
• zu (11): standardmäßig sind 3 verschiedene Teile des Klassenpfades definiert;
• zu (12): das jar-File landet im Build-Bereich;

Wie auch im Fall von Domain- und Test-Code, erhalten auch die Fixtures ein eigenes Verzeichnis (Folder):

 |-/home/Horst/06-01-FitNesse-Examples/userStoryList
 | =================================================
 |   |
  ...
 |   |
 |   |-sources
 |   | =======
 |   |   |
 |   |   |-userStoryList
 |   |   | =============
 |   |   |   |
 |   |   |   |-fitnesse
 |   |   |   | ========
 |   |   |   |   |
 |   |   |   |   |-de
 |   |   |   |   | ==
  ...............
 |   |   |   |
 |   |   |   |-src
 |   |   |   | ===
 |   |   |   |   |
 |   |   |   |   |-de
 |   |   |   |   | ==
  ...............
 |   |   |   |
 |   |   |   |-test
 |   |   |   | ====
 |   |   |   |   |
 |   |   |   |   |-de
 |   |   |   |   | ==
  ...............
 

• die hier nicht sichtbare Konvention: Test- bzw. Fixture-Code liegen im gleichen Package;

Auf der Frontpage auf eine spezielle Wiki-Seite verweisen, die alle Imports zeigen wird:

 !1 Demonstrate "Wiki-Imports", used by Developers.

 !2 MyImportsForDevelopment 

Beispiel: so sieht es aus ...

Auf meiner persönlichen Import-Seite stehen alle Projekte, an denen ich entwickle:

 !3 Settings to provide local support for remote import:
 '''Variables'''
 !define developmentWorkspace {/home/franzkeh/workspace.2-1-1}
 ----
 !3 List of Imported Projects
  * ^ImportProjectUserStoryList 

Beispiel: so sieht es aus ...

• die Variable 'developmentWorkspace' verweist auf das Wurzel-Verzeichnis meines (Eclipse-) Workspace; dort liegen die Verzeichnisse der Projekte;
• mit diesem Verweis lenke ich mein lokales FitNesse auf die Klassen, die mir meine IDE während der Entwicklung aktualisiert;

wie unter FitNesse-Import beschrieben, ist hier das Projekt vom Zentralen FitNesse-Server über die Properties dieser Seite importiert worden:

 !3 Settings to provide local support for remote import:
 '''Variables'''
 !define COLLAPSE_SETUP {true}
 !define COLLAPSE_TEARDOWN {true}
 !define projectName {userStoryList}

 '''Classpaths'''
 !path ${developmentWorkspace}/${projectName}/classes
 !path ${developmentWorkspace}/${projectName}/vendor/lib/fitlibrary.jar
 !path ${developmentWorkspace}/${projectName}/vendor/lib/fitnesse.jar
 ----
 !3 Contents
 !contents -R 

Beispiel: so sieht es aus ...

• wichtig ist die Definition des Klassenpfades: hier kommt die Variable für meinen IDE-Workspace zum Einsatz;
• Dritt-Bibliotheken nicht vergessen (hier nur als Beispiel);
• Tipp: setzen Sie für diese Seite auch noch das Property 'Suite'; dann können Sie auf einen Klick alle importierten Tests/Suites ausführen;

Mit dem CommandLineTestRunner von FitNesse lassen sich die Kunden-Tests von einem beliebigen Zentralen FitNesse-Server einfach und schnell in ein Ant-Build-Skript einbinden;
z.B. so:

<?xml version="1.0" ?>
<!--
  #######################################################################
  Ant-Build-File: Fitnesse Test-Runner;
  =================================================================
  14.05.2006	Horst Franzke (www.horstfranzke.de)
  #######################################################################
-->

<project name="Fitnesse-Test-Runner" default="run.fitnesse" basedir=".">

  <property name="fitnesse.test.or.suite.to.start.at"                          // (1)
            value="ProjectGroupHorst.ProjectUserStoryList" />
  <property name="report.build"                                                // (2)
                value="." />
  <property name="fitnesse.jar.dir"                                            // (3)
                value="/home/tools/fitnesse" />

  <target name="run.fitnesse" 
          if="fitnesse.test.or.suite.to.start.at">                             // (4)

    <property name="fitnesse.report.dir"                                       // (5)
              value="${report.build}/fitnesse" />
    <mkdir dir="${fitnesse.report.dir}" />

    <property name="result.file.for.fitnesse.html"                             // (6)
              value="${fitnesse.report.dir}/fitnesse-result.html" />

    <property name="fitnesse.server"                                           // (7)
              value="localhost" />
    <property name="port.of.fitnesse.server" 
              value="4000" />

    <path id="fitnesse.classpath">
       <fileset dir="${fitnesse.jar.dir}">                                     // (8)
          <include name="fitnesse.jar" />
          <include name="fitlibrary.jar" />
       </fileset>
    </path>

    <echo message="Fitnesse running on ${test.or.suite.to.start} ..." />

    <java classname="fitnesse.runner.TestRunner" 
          classpathref="fitnesse.classpath"
          fork="true"
          dir="."
          failonerror="true"                                                   // (9)
          >
      <arg line="-v                                                            // (10)
                 -html ${result.file.for.fitnesse.html}
                 ${fitnesse.server} ${port.of.fitnesse.server} 
                 ${fitnesse.test.or.suite.to.start.at}"/> 
    </java>

    <echo message="Target 'run.fitnesse' finished OK." />
  </target>

</project>
 

• zu (1): hier geben wir den kompletten Wiki-Pfad zur Projekt-Seite an; damit werden alle Kunden-Tests zum Projekt durchlaufen;
• zu (2): ich erzeuge mir für jeden Build-Lauf ein eigenes Report-Verzeichnis (z.B. mit Zeitstempel oder Build-Id im Namen); und in dieses Report-Verzeichnis möchte ich auch den FitNesse-Report stellen;
• zu (3): Geschmackssache: diesen Verweis benutze ich unten, um mir fitnesse.jar in den Klassen-Pfad zu holen; könnte man aber auch aus den projekt-spezifischen 'vendor/lib'-Verzeichnis holen;
• zu (4): FitNesse soll eigentlich nur loslaufen, falls es Sinn macht - d.h. falls auch Test-Seiten zum Projekt vorhanden sind; über dieses Property läßt sich auch einfach steuern, ob FitNesse starten soll oder nicht (z.B. falls die Kunden-Tests korrupt wären, man aber dringend eine aktualisierte Software-Version ausliefern muß);
• zu (5): ich spendiere ein eigenes Unterverzeichnis für den/die FitNesse-Reports;
• zu (6): das FitNesse-Report-File;
• zu (7): 2 Properties für den Zugang zum Zentralen FitNesse-Server;
• zu (8): in der Regel wird man wohl immer auch die FitLibrary im Einsatz haben;
• zu (9): wie gesagt: wir wollen den Build (mit welchem Ziel auch immer) stoppen, sobald auch nur ein Kunden-Test fehlschlägt - natürlich um den Fehler sofort zu heben (und nicht, um FitNesse über das Property oben abzuschalten!);
• zu (10): Details zu den Optionen siehe im Original "CommandLineTestRunner";