Tester pour contruire le bon logiciel: la relève...

le 23/04/2007 par Olivier Mallassi
Tags: Product & Design

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J'en entends déjà pester "encore un truc de geek"...Le pilotage par les tests se résume à ces deux points clés:

  • remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l'ambiguïté du langage courant par des spécifications exécutables c'est à dire vérifiables concrètement et fournissant une réponse sans appel: "vert" ou "rouge".

  • Piloter non pas sur un "reste à faire" - concept obscur car que met on dans le "reste à faire"? - mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d'avoir un outil permettant aux "fonctionnels" d'écrire simplement - c'est à dire dans leur vocabulaire - les spécifications exécutables et permettant aux "managers" de piloter les développements.

Le seul outil existant jusqu'à ce jour était Fitnesse (http://fitnesse.org/) et se présente sous la forme un wiki (autrement nommé "repository de test") utilisant un noyau nommé FIT (http://fit.c2.com/) pour exécuter les tests ou "spécifications exécutables" et ainsi réaliser les assertions.

Nos retours d'expérience nous ont montré des limites - non pas de l'approche - mais de l'outil. Alors, nous nous sommes remis en quête de mieux et nous avons découverts des initiatives comme Greenpepper (http://www.greenpeppersoftware.com), initiative qui répond à presque toutes nos douleurs:

  • Problématique d'Edition. Le wiki et la syntaxe proposée apparaît comme un élément essentiel à une émancipation de l'écriture des spécifications exécutables chez les "fonctionnels". Non seulement parce que le manque d'éditeur WYSIWYG est un frein notable dans la prise en main d'un wiki par des gens peu ou pas habitués à manipuler des langages informatiques mais aussi car la manipulation de tableaux - structure exécutable - complexes devient très vite problématique, même pour des caïds en perl...Alors Greenpepper s'appuie à ce jour sur un Jira mais surtout sur un wiki Confluence dont l'éditeur de page est extrêmement puissant et propose des fonctionnalités comme le copier/coller depuis excel...

  • Problématique de Build et outillage. Une limitation importante est liée au développement des Fixtures - ce code qui réalise la liaison entre le test exprimé dans le wiki et le code a tester - . Comment simplement exécuter la Fixture en cours de développement? la solution actuelle est simple mais peu acceptable: construire le jar correspondant et le positionner dans le classpath de Fitnesse. C'est simple mais dans des infrastructures complètes - faisant intervenir automate de build, repository maven..., la perte de productivité se fait très rapidement sentir. Alors Greenpepper propose un plugin eclipse qui fluidifie énormément le travail de développements des fixtures et le travail collaboratif autour des tests.

L'intégration aux usines de développement et notamment avec maven nous semble également apporter un grande valeur ajoutée et à jusqu'à présent donner lieu à quelques développement de plugins pour maven1 ou maven2 (http://mojo.codehaus.org/fitnesse-maven-plugin/index.html). Là encore, Greenpepper propose son plugin pour Maven2 et permet d'intégrer l'exécution des spécifications au build.

  • Concernant l'intégration à l'infrastructure, Greenpepper s'appuie sur des briques standards, connues et reconnues par "l'exploitation": un war et un tomcat. Cela peut paraître anodin mais peut grandement simplifier le déploiement et l'administration de l'outil au niveau de l'entreprise.

Malgré tout, une autre limite liée au versionning du logiciel subsiste. Le logiciel n'est plus seulement le code: c'est le code, les tests unitaires et les spécifications exécutables. Ainsi, une release du logiciel doit inclure une version (et par extension une release) des spécifications exécutables. Actuellement, cette limitation reste sans réponse et il est nécessaire de gérer "a la mano" les versions des spécifications exécutables ce qui pour des applications conséquentes (plusieurs centaines de tests) peut devenir acrobatique.

Enfin, GreenPepper ne propose encore rien concernant l'aspect reporting, à la fois sur les aspects historiques d'exécution ou pilotage. On peut trouver cela un peu dommage, sauf que tout est déjà présent en base de données.

Alors, nous avons réalisé quelques essais de rapports comme l'historique d'exécution des tests ou bien encore la vélocité.

Ces rapports ont été simplement créés sur la base de plugins Confluence et l'exécution de script Groovy (http://groovy.codehaus.org/) et il y a fort à parier que ce genre de features fera partie des prochaines releases.

GreenPepper semble donc être un nouvel élément du marché proposant pour un coût plus que raisonnable (~$3000 pour 25 utilisateurs) des réponses industrielles aux problématiques de pilotage par les "spécifications exécutables".

Affaire à suivre...