FitNesse, Maven, Hudson : pour une intégration continue des tests d’acceptance

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

Intégration avec Maven

Classpath generator

Dès qu’on joue un peu avec FitNesse, on se rend vite compte que la gestion du classpath est une vraie galère ! L’écriture manuelle n’est pas une solution envisageable lorsque le projet embarque plus d’une dizaine de dépendances. Et puis après tout c’est le rôle de Maven de gérer tout ça !

C’est là qu’entre en jeu le superbe plugin Classpath generator.

Compatible avec la dernière version de FitNesse (20090818), il permet de générer automatiquement la liste des dépendances des fixtures décrites dans le pom, directement dans le wiki.

Pour savoir comment configurer le plugin et comment l’utiliser, il suffit de suivre ce lien.
Attention, la page dans laquelle vous souhaitez générer le classpath doit être de type « Suite ».

Trinidad

L’étape suivante consiste à intégrer l’exécution automatique des tests d’acceptance dans le processus de build du projet. Pour cela, il existe le plugin Maven nommé Trinidad. Nous nous concentrons ici uniquement sur l’aspect exécution des tests FitNesse dans Maven, sachant que le plugin permet de faire bien plus que ça.

Pour cela, je vous décris dans la suite comment j’ai configuré et utilisé le plugin.

Configuration du pom.xml du projet contenant les fixtures :

Ajout de la dépendance :

<project>  
  <repositories>  
    <repository>  
      <id>neuri-maven</id>  
      <url>http://maven.neuri.com/</url>  
      <snapshots>  
        <enabled>true</enabled>  
      </snapshots>  
      <releases>
        <enabled>true</enabled>  
      </releases> 
    </repository>  
  </repositories>  
  <dependencies> 
    <dependency>  
      <groupid>com.neuri.tdd</groupid>  
      <artifactid>fitnesserunner</artifactid>  
      <version>20090818</version>  
    </dependency> 
  </dependencies> 
</project>

Configuration du plugin :

<project>
  <build>
    <plugins>
      <plugin>
        <artifactid>maven-trinidad-plugin</artifactid>
        <version>20090818</version>
        <executions>
          <execution>
            <phase>test</phase>  
            <goals>
              <goal>run-tests</goal>
            </goals>  
          </execution>
        </executions>
        <configuration>
          <testengine>slim</testengine>  
          <testrepositorytype>fitnesse</testrepositorytype>
          <testrepositoryuri>C:\Programs\fitnesse</testrepositoryuri>  
          <breakbuildonfailure>true</breakbuildonfailure>  
          <suites>  
            <suite>MyProject.MyTestSuite</suite>  
          </suites>  
        </configuration>
      </plugin>  
    </plugins>  
  </build>  
  <pluginrepositories>  
    <pluginrepository>  
      <id>neuri-maven</id>  
      <url>http://maven.neuri.com/</url>  
      <snapshots>  
        <enabled>true</enabled>  
      </snapshots>  
      <releases>  
        <enabled>true</enabled>  
      </releases>  
    </pluginrepository>  
  </pluginrepositories> 
</project>

Ainsi configuré, tous les tests FitNesse inclus dans la suite « MyTestSuite » seront exécutés lors du lancement de la phase test de Maven.

Le paramètre « breakBuildOnFailure » permet comme son nom l’indique de casser le build en cas d’échec sur les tests d’acceptance. Par défaut, le paramètre est à false.

Hudson

L’usine d’intégration continue est une brique logiciel essentielle dans un projet agile. Il garantit l’intégrité de l’application construite au fil de l’eau. Hudson est un des outils les plus répandus. Intégrer les tests d’acceptance dans l’usine d’intégration continue participe donc à construire un logiciel de qualité.

Par contre, on est en droit de se demander s’il est indispensable d’exécuter les tests d’acceptance à chaque fois que l’application est construite (c’est-à-dire à chaque commit d’un développeur). En effet, les tests FitNesse sont souvent longs à exécuter, et les jouer à chaque fois peut parfois nuire à la productivité de l’équipe. Un bon compromis est de lancer le build des tests d’acceptance toutes les nuits.

Voici comment j’ai configuré le job Hudson qui exécute les tests FitNesse tous les jours à minuit:

hudson1

hudson2

Malgré une version stable depuis Août 2009, FitNesse peut être amené à évoluer dans quelques mois. Cet article se base sur la version 20090818. Les outils présentés ont été testés sur cette version. Il n’est pas garantit qu’ils fonctionneront toujours avec les versions futures de FitNesse.