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 :

  • 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) !

Publié par

Publié par Nathaniel Richand

Expert Java, passionné par les méthodes agiles, les tests et l’industrialisation des pratiques de développement.

Commentaire

9 réponses pour " Premiers pas avec GreenPepper XWiki "

  1. Publié par , Il y a 9 ans

    Super article, merci. J’attendais un retour de la version XWiki de Greenpepper (que je n’ai pas encore teste)…

  2. Publié par , Il y a 9 ans

    Bravo pour cet article complet, le domaine des tests fonctionnels automatisé est encore assez peu exploité. Je ne connaissais pas de concurrents à Fit/Fitnesse, content de voir que le marché se dynamise.

    Question de noob : pourquoi vouloir absolument utiliser un WIKI pour exprimer les tests ? Est-ce que le degré de liberté et la syntaxe alambiquée ne risquent pas de faire fuir les fonctionnels, qui ne sont pas forcément fans des trucs de geek ? Au final, l’écriture des tests varie assez peu, qu’est-ce qui fait que Fitnesse et GreenPepper préfèrent un format Wiki à une UI plus contrainte ?

  3. Publié par , Il y a 9 ans

    Très bon article, un sujet pas facilement abordable surtout à cause de la procédure d’installation de greenpepper.

    Je trouve que la combinaison XWiki-GPP et plus simple à aborder que la combinaison Confluence-GPP.

    Nabil ADOUANI

  4. Publié par , Il y a 9 ans

    @Piwaï
    Je suis d’accord avec toi pour dire que le wiki peut paraître assez rebutant pour un public peu technique. Cependant, le wiki s’est bien démocratisé, à la fois en entreprise et chez les particuliers (l’effet wikipédia). De plus, en choisissant Confluence et XWiki, les équipes de GreenPepper ont pris des wikis avec des interfaces riches qui peuvent permettre aux fonctionnels de ne pas utiliser la syntaxe wiki (au moins 90% du temps). On peut même importer des documents office pour les cas désespérés :)

    En contraignant l’interface on perd de la liberté de s’exprimer et de documenter les tests. Par exemple Robot Framework ne contient que la partie tabulaire brute. Personnellement, je trouve ça trop léger, j’aime pouvoir rajouter facilement des explications, des schémas.

    Donc au final pourquoi pas le wiki, tant qu’on n’aura rien trouvé de mieux. Une idée ?

  5. Publié par , Il y a 8 ans

    Bonjour,

    Avant toute chose, je tenais à vous remercier sincèrement pour votre article, qui m’a permis de comprendre beaucoup plus facilement GreenPepper.

    Je suis actuellement en train d’essayer de le mettre en place pour certains projets, mais je n’arrive pas à le faire fonctionner avec Maven. J’ai pourtant suivi l’intégralité de votre tutoriel, à ceci prêt que je ne suis pas certain de mon projet de fixture / sut. Serait il possible que vous partagiez le code source que vous avez utilisé pour réaliser ce test s’il vous plaît ?

    Je vous en serai extrêmement reconnaissant. Je vous remercie encore pour votre aide,

    Cordialement.

  6. Publié par , Il y a 6 ans

    Twist est également une solution séduisante!

  7. Publié par , Il y a 4 ans

    Bonjour,

    Etant en recherche de toutes les références de GreenPepper, je suis arrivé sur cet article.
    Je tenais à vous informer que Pixis a ouvert le code source de GreenPepper et de certains addons. Malheureusement, le plugin XWIKI n’en fait pas parti.
    Nous avons forké le code pour continuer la maintenance de ce bel outil. Bien entendu, toute personne intéressée peut y contribuer.
    Retrouvez nous sur http://strator-dev.github.io/greenpepper/

  8. Publié par , Il y a 4 ans

    Bonjour Oumar,

    Bravo, belle initiative. Pour le plugin XWiki c’est bien dommage car XWiki est open source (LGPL). Avez-vous contacté Pyxis pour savoir pourquoi il ne l’ont pas open-sourcé ? Peut-etre seraient-ils ok de le faire ?

    Sinon, je suis un committer sur le projet open source XWiki et si vous avez des questions XWiki et si on peut aider, n’hesitez pas a nous contacter sur http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists

    Merci !
    -Vincent Massol

  9. Publié par , Il y a 4 ans

    Merci Vincent,

    En fait, j’ai dû ‘harceler’ Pyxis pour qu’ils libèrent le code (D’autres l’ont certainement aussi fait). Du coup, j’hésite à repartir sur une autre bataille pour le reste. Mais tu as bien raison, je vais leur envoyer un mail.

    En rapport avec XWiki, à l’époque où j’ai connu Greenpepper, il y avait un pack de démo avec XWiki. J’ai voulu refaire ce pack, mais j’ai l’impression que XWiki a pris un certain nombre de méga bytes en quelques années ^_^ . Est ce qu’il y aurait une version light disponible ?

  10. Publié par , Il y a 3 ans

    Salut Oumar,

    Desole pour ma reponse tardive ! :)

    Pour repondre a ta question, oui XWiki a pris du poids au fur et a mesure des années. Je viens de grapher l’evolution ici: https://www.evernote.com/l/AHe8M7Mpc8dLYbLXUUR4BNshyArvRhxM2e4

    Et j’ai lancé un thread sur le sujet:
    http://markmail.org/message/or4k4pcar5da4kmg

    Si tu as besoin d’aide sur XWiki n’hesite pas a nous poser des question sur IRC ou sur la liste (http://dev.xwiki.org/xwiki/bin/view/Community/IRC et http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists). On sera ravi de pouvoir t’aider sur tu as envie de faire qq chose.

    Merci
    -Vincent

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.