Premiers pas avec GreenPepper XWiki

Adepte de longue date de Fitnesse, j’ai toujours aimé l’aspect collaboratif du wiki permettant de sortir les tests du code et de les exposer à d’autres populations moins technique. Cependant, malgré le succès du projet et la grande communauté qui l’entoure, Fitnesse reste compliqué à mettre en place et certaines fonctionnalités de bases font cruellement défaut. De plus, le passage de Fit à Slim a fortement contribué à complexifier le projet.
Pour moi, Fitnesse est un projet passionnant et porteur de nombreuses innovations. Cependant, l’absence de structuration et le manque de documentation le rend très difficile à mettre en oeuvre et demande une réelle expérience. Je vous conseille tout de même de garder un oeil sur celui-ci, car, depuis l’année dernière, le projet est redevenu très dynamique (pas moins de sept releases) et semble gagner en maturité (je vous conseille notamment cet article sur les nouveautés).

J’ai plusieurs fois dans le passé eu l’occasion de voir des présentations de GreenPepper par les équipes de Pyxis. GreenPepper partage le même concept que Fit/Fitnesse mais a fait le choix de s’appuyer sur un Wiki existant robuste et mature : Confluence. Ce choix est un des gros atouts de GreenPepper, mais c’est aussi la raison qui m’a toujours fait écarter cette alternative. En effet, j’ai toujours trouvé difficile de promouvoir un logiciel en expliquant qu’il faudrait non pas acheter une mais deux licences (pour les entreprises non équipées en Confluence) et qu’il faudrait configurer et maintenir les deux logiciels.

Cependant, ce point de blocage a été adressé lors de la version 2.6 sortie en novembre 2009, qui permet désormais de pouvoir faire reposer GreenPepper sur XWiki qui est gratuit et open source.

Je vous propose donc de m’accompagner dans le test de cette nouvelle version au travers de cet article qui aborde :

• l’installation de GreenPepper et la configuration de XWiki,
• la création des premiers tests,
• la configuration de Maven et Eclipse pour GreenPepper,
• la création des fixtures,
• un petit retour d’expérience,
• mes espoirs pour le futur.

Avant de vous lancer dans la lecture de cet article, notez que celui-ci est purement technique et nullement philosophique. La présentation de l’ATDD (Acceptance Test Driven Development) ne sera pas abordée ici.

Installation de GreenPepper et configuration de XWiki

Pour ce test, je suis parti sur la version Standalone avec Jetty et HsqlDB embarqués. Téléchargement, unzip, start_xwiki.bat, c’est parti!

Je me connecte avec un login d’administrateur pour configurer GreenPepper (par défaut Admin/admin). Il faut noter qu’il n’y a pas de groupe de droits dédié pour GreenPepper, uniquement le groupe « greenpepper-users » destiné à identifier les utilisateurs autorisés pour la version avec licence.

Pour les besoins de ce test, je saisis un numéro de licence d’essai.

Puis je me crée un nouvel espace qui va accueillir les tests de mon application. Ici, un batch créé précédemment pour les besoins d’un XKE :

Et je définis mon espace comme un projet GreenPepper :

Création des premiers tests

Le wiki étant prêt, je peux passer à l’écriture de mes premiers tests. Pour cela, je commence par créer une page pour accueillir mon test :

Premier test

Pour mon premier test je vais tester le format do with qui correspond à un flow, voici mon test en format wiki :

|= import| fr.xebia.batch.fixture

Ce test va simplement lancer mon batch et m'afficher en couleur le résultat d'exécution :
|= do with|=xebian
|lancer le batch

Cependant, il est très agréable également d’utiliser l’éditeur WYSIWYG. Celui-ci fera plaisir au gens du métier qui n’aime en général pas trop la syntaxe Wiki :

Il existe des compléments dans fitnesse tels RichNesse pour avoir un éditeur graphique, mais cette alternative était assez buggée lors de ma dernière utilisation…

Second test

Pour ce deuxième test je vais essayer le format scenario. Ce format est assez révolutionnaire, et permet d’écrire une spécification de manière naturelle sans devoir découper dans un tableau le passage de variables. Pour récupérer dans le code les variables, on procèdera par des expressions régulières (voir plus bas).

{{greenpepper-import parameter="fr.xebia.batch.fixture"/}}

|= Scenario |= XebianScenario
|= lancer le batch xebia avec le fichier toto.xml
|= vérifier que les 2 affaires ont été créées

Les variables qu’il nous faudra récupérer sont « xebia », « toto.xml » et « 2 ». A noter que j’ai utilisé ici la macro import. Son intérêt est de masquer le tableau contenant les imports de package. Ainsi notre page ne contient que des données métiers et aucune donnée technique :

Organisation des tests

Lorsque nous avons plusieurs tests, nous voulons pouvoir exécuter tous nos tests en un seul clic, ou bien tous les tests correspondants à une story donnée. Sous GreenPepper, on retrouve la notion de Suite existant dans Fitnesse. Pour faire ceci, j’ai trouvé deux macros différentes. Soit la macro children greenpepper-children expanded="true"/ qui va récupérer toutes les pages GreenPepper filles, soit la macro labels qui va récupérer toutes les pages d’un tag donné, par exemple : {{greenpepper-labels spaceKey="GreenPepper Batch" title="Batch" labels="Batch" expanded="true" openInSameWindow="true"/}}. Voici ce que donne nos deux macros :

Configuration de Maven et Eclipse

Configurer un projet java simple sous GreenPepper est trivial (tout comme sous Fitnesse). Il suffit d’utiliser le runner Java et de définir le chemin vers les jars que l’on teste, notre SUT (System Under Test), ainsi que le chemin vers nos fixtures (nos tests qui vont appeler notre SUT).

Maven

Le challenge pour moi, était de voir comment se comportait GreenPepper avec Maven. J’avais été très déçu par Fitnesse qui a pendant très longtemps dénigré Maven malgré sa popularité. S’il existe beaucoup de solutions pour intégrer Maven à Fitnesse, aucune ne fonctionne vraiment. Après m’être arraché les cheveux, j’avoue avoir fini par me faire ma propre solution ‘bancale’.

Pour intégrer Maven à GreenPepper, j’ai au final dû passer deux heures maximum (en me faisant aider par le forum cependant). A noter que l’intégration de Maven n’est pas parfaite, mais elle a le mérite d’être fonctionnelle. Elle se contente de chercher les <dependencies> définie dans le pom.xml.

Procédure d’installation (voir également la documentation) :

Copiez le jar du runner maven (à télécharger) dans le répertoire : greenpepper/maven/runner

Ajoutez un nouveau Runner :

• Command Line :

java -mx252m -cp ${classpaths} ${mainClass} ${inputPath} ${outputPath} -l ${locale} -r ${repository} -f ${fixtureFactory} --xml --pdd ${projectDependencyDescriptor}

• Main class : com.greenpepper.maven.runner.Main
• Environment : Java

• Ajoutez dans la partie classpath le runner maven ainsi que les jar de maven embedded :

greenpepper/maven/runner/greenpepper-maven-runner-2.7-complete.jar
C:\apache-maven-2.2.1\lib\maven-2.2.1-uber.jar
C:\apache-maven-2.2.1\boot\classworlds-1.1.jar

Ensuite, définissez votre SUT en renseignant le nouveau Runner Maven ainsi que le chemin vers le pom.xml (Project dependency descriptor) :

Attention 1 : Il ne faut pas renseigner les champs « System under test classpaths » et « fixture classpaths » qui rentrent en conflit avec la définition du pom.xml.
Attention 2 : De part l’utilisation de maven embedded, le fichier settings.xml de maven n’est pas utilisé. Il faut donc placer son dépôt local dans le répertoire par défaut (user/.m2/repository). Si cela vous pose problème, suivez l’évolution de la JIRA associée.

Et voilà, tout fonctionne correctement :-)

Eclipse

Autre déception pour moi avec Fitnesse, son manque d’intégration avec nos IDE. Il existe quelques embryons de projets d’intégration de Fitnesse et Eclipse, mais je n’ai jamais réussi à avoir quelque chose qui soit véritablement fonctionnel …

Voici ma procédure avec GreenPepper :

• Installer le plugin depuis l’update site : http://www.greenpeppersoftware.com/greenpepper-eclipse

• Configurer le plugin, dans windows => preferences :

Server’s context path : http://localhost:8080/xwiki/greenpepper/xmlrpc
Server’s XML RPC handler : greenpepper1

• GreenPepperiser le projet depuis le menu « GreenPepper ».

• Configurer le SUT dans les paramètres du projet (project->properties->GreenPepper).

Il y a beaucoup d’options, j’ai juste sélectionné dans la liste mon projet, mon SUT et renseigné un lien vers mon runner (C:\greenpepper-xwiki-enterprise-jetty-hsqldb-2.7\greenpepper\java\runner).

Après avoir fait ceci, mes tests remontent directement sous Eclipse et sont exécutables :

Création des fixtures

Après avoir écrit nos tests, il faut maintenant faire le lien avec le code que l’on souhaite tester en créant des fixtures.

• Test 1 (Do with):

Cette fixture, va être appelée par notre premier test défini plus tôt.

public class XebianFixture {

    public boolean lancerLeBatch(){
  //Exécute mon batch
  return "COMPLETED".equals(monBatch.getExitCode());
    }
 }

• Test 2 (Scenario):

Rajouter la dépendance vers GreenPepper dans le projet de fixtures pour avoir les annotations :

      greenpepper-open
      greenpepper-core
      2.7
  

   
      
    GreenPepper
    GreenPepper
    http://www.greenpeppersoftware.com/nexus/content/groups/public
      
   

Puis faire le lien avec notre code à tester :

public class XebianScenarioFixture {

  int resultingAffaire;

  @Given("lancer le batch (\\w+) avec le fichier (\\w+\\.xml)")
  public void launch(String batchName, String fileName){
    System.out.println(batchName);
    System.out.println(fileName);
    //Appeler notre batch et stocker le nombre d'affaire créées dans resultingAffaire
  }

  @Check("vérifier que les (\\d+) affaires ont été créées")
  public boolean verifyResult(int expectedAffaire){
    return expectedAffaire == resultingAffaire;
  }
}

On voit que le mode scénario apporte de nombreux avantages. Outre le fait de pouvoir écrire des tests de manière très naturelle, nos fixtures deviennent également beaucoup plus lisibles ! Les méthodes ne possèdent pas de noms à rallonge comme sous Fitnesse et, de plus, l’intention de la méthode est clairement exprimée par l’annotation (@Given, @When, @Then, @Check, …). Les arguments sont automatiquement mappés grâce aux expressions régulières qui restent relativement triviales à écrire. Si vous cherchez plus d’exemples, je vous propose un article sur le blog de GreenPepper. Mon seul bémol porte sur l’utilisation de l’annotation @Then que je n’ai pas encore bien compris, je lui préfère le @Check pour le moment.

Retour d’expérience

Vous aurez donc compris à la lecture de cet article que j’ai vraiment été conquis par GreenPepper. Au bout de seulement quelques heures je me sens à l’aise et pleinement prêt à l’utiliser.

Thomas, il y a un peu plus d’un an, parlait dans son article (que je vous encourage à lire) de certaines difficultés rencontrées lors de la mise en place de GreenPepper, dont notamment la documentation, Eclipse et Maven. Le produit a bien évolué depuis (3 releases en 2009) et je n’ai pas du tout rencontré ce genre de soucis. Au contraire, je trouve la documentation plutôt bonne ce qui compense l’absence de réelle communauté autour du projet (c’est exactement l’inverse avec Fitnesse).

Enfin, une note particulière sur le support : félicitations ! J’ai connu des supports payants totalement incompétents, dont je ne citerai pas les noms, qui se contentaient de vous recommander d’acheter la version supérieure. Ici, je n’ai pas déboursé un seul centime et j’ai eu des réponses pointues dans un délai variant de 10 minutes à quelques heures (et encore l’équipe de développement semble être au Canada). Un grand merci aux équipes de GreenPepper et plus particulièrement à François Denommée pour leur professionnalisme.

Futur

La version de GreenPepper sur XWiki est encore jeune (fin de l’année 2009) et certaines fonctionnalités ne sont encore présentes que dans la version confluence. On attend donc encore certaines fonctionnalités avec impatience (ce qui ne devrait pas tarder vu le dynamisme du produit).
Parmi celles-ci, j’en retiens trois particulièrement qui continueront de rendre ce produit indispensable :

• la notion de « tag as implemented » : le testeur ou la personne du métier rédige le cas de test, or celui-ci n’est pas exécutable tant que le développeur n’a pas créé la fixture associée.

Ce flag permet de marquer (directement depuis Eclipse) que le test est prêt à être exécuté.

• La macro historique d’exécution : cette macro permet de suivre l’évolution de l’exécution des tests dans le temps.
• La macro include : qui permet d’inclure une page de test dans un autre test. Cette fonctionnalité est très intéressante notamment dans le cas où on a une page qui contient l’initialisation de données communes à plusieurs tests.

Voilà, je vous laisse maintenant avec toutes les cartes en main pour essayer. Bons tests à vous (dans les 2 sens) !