"Vincent, sincèrement, je comprends pas, on est pas censés faire de concessions au niveau de l'expression de nos besoin par les tests automatisés, mais d'un autre côté, plus le temps avance, plus on tord ce qu'on exprime pour que ça facilite le travail des développeurs. Faire des tableaux, des listes et tout ça, c'est parfois douloureux." Martine AMOA.

Exemple de test de recette automatisé Greenpepper

Demander à une AMOA de spécifier par les tests est souvent déroutant pour des équipes habituées à fonctionner à coup de spécifications plus "classiques". Si en plus les outils sensés supporter cette nouvelle méthode de travail amènent avec eux une douleur, il est d'autant plus difficile de faire passer les messages vraiment essentiels:

• automatisation des specifications au travers de tests afin de diminuer les temps de recette
• fournir aux équipes de développement des user stories priorisés par valeur métier.

Et c'est vrai que certains outils de tests d'acceptance/recette sont parfois bizarre. Je veux dire, pourquoi est ce que je devrais faire tout un tas de tableaux (d'une seule ligne souvent) pour exprimer un scénario de test? Parler de ces outils n'est pas le sujet de cet article. Non, aujourd'hui, je voudrais introduire Cucumber. Un gentil petit outil de tests de recette automatisés frais et léger.

Du langage naturel et autres friandises sucrées

Langage Naturel...

"Alors déjà Vincent, nous, franchement, quand on relit nos tests, on reconnait plus certaines choses... C'est quoi tous ces mots clés qui apparaissent dans nos tests après le passage des développeurs? Ca devient illisible!" Sandie AMOA.

Et si, messieurs dames de l'AMOA, vous utilisiez le langage naturel? Si, chaque action de votre scénario de recette était une jolie phrase en français, sans tableau? Et si, vous aviez juste à utiliser ce formalisme simple (décrit par ailleurs par "M. SCRUM" ici):

1. Afin de <Valeur>, En tant que <Utilisateur>, Je veux <Fonctionnalité>
2. Soit le <contexte> suivant
3. Lorsque j'effectue une <action>
4. Alors il devrait se passer/je devrais voir...

Deconstruisons ces 4 étapes:

1. Afin de <Valeur>, En tant que <Utilisateur>, Je veux <Fonctionnalité>

Définir la fonctionnalité, à partir desquelles vont découler un certain nombre de scénarios de tests. Cette partie n'est pas exécutée, le formalisme est donc totalement libre. Il est cependant important de rappeller la valeur de la fonctionnalité, et la fonctionnalité en elle même.

Nous passons donc ensuite à la description des scénarios eux même.

2. Soit le système dans une situation particulière...

Ici, on met en place le système, le contexte. Cela consiste en général à établir un certain nombre d'objets métiers déjà présents, de la situation de départ. Par exemple: "Soit un forfait de 2h pour 40€/mois avec un hors forfait de 1€/min Et que j'ai une communication de 30 minutes". Simple, efficace et direct. On remarque ici le mot clé "et" qui permet d'enchainer les "Soit" sans les répéter et ressembler réellement à du langage parlé.

3. Lorsque j'effectue cette action...

Dans cette étape, on effectue notre action, par exemple: "Lorsque je calcule le total de la facture".

4. Alors il devrait se passer/je devrais voir...

Enfin, on vérifie que l'action s'est bien déroulé, par exemple:

"Alors le total de la facture doit être de 40€".

Et oui, cucumber, c'est globalement aussi simple que cela. Et dans la langue que vous voulez. Car le concombre est polyglote. On peut même créer sa propre langue! Pour cela, rien de plus simple, il suffit de modifier le langage.yml situé dans le répertoire de la gem Cucumber.

Du coup, dans votre fichier texte, ça donne ça:

Simple et innovant.

Ne nous occupons pas de ce que les développeurs feront de ce cas de test (Cet article de Rémy Christophe traite du sujet). La chose importante à savoir, c'est qu'ils ne modifieront ABSOLUMENT RIEN dans ce fichier. Rien. AMOA, je vous vois déjà sourire.

... et autres friandises sucrées

Contexte Partagé

"Franchement, je ne me vois pas rentrer tout le contenu de mon système avant TOUS mes scénarios de tests. Ca va être trop long! Surtout que c'est tout le temps la même chose!" Christophe AMOA.

Oui c'est vrai. Pour ça Cucumber, Cuke, pour les intimes, propose une gestion de contexte simple. Il suffit, juste après la définition de votre fonctionnalité, de définir le contexte pour TOUS les scénarios qui vont arriver après, et cela, en utilisant le mot Contexte (Background en VO). Ainsi, ce qui aurait pu être une tache répétitive (copier/coller) se transforme en jeu d'enfant. Attention tout de même à ne pas en abuser. Si votre contexte est trop gros, c'est peut être que vous voulez tester TROP de choses. Et donc que vous voulez adresser une fonctionnalité trop grosse aux développeurs. Et c'est mal! En prenant une nouvelle fonctionnalité:

Execution partagée

"Franchement Vincent, tes exécutions de règles de gestion, on peut pas les appliquer à des scénarios entiers, les mutualiser histoire d'éviter de se répeter?" Aline AMOA.

Alors là, je vais un peu expliquer, parce que ce n'est pas forcément très clair. Prenons une fonctionnalité simple: "Afin d'assurer la qualité du contenu de mon site, en tant qu'utilisateur enregistré mais non connecté, je veux pouvoir me connecter."

On peut imaginer plusieurs scénarios de tests:

1. j'arrive a me connecter
2. je n'arrive pas a me connecter à cause de mon mot de passe
3. je n'arrive pas a me connecter à cause de mon nom d'utilisateur.

Ca fait donc trois scénarios.

Mais en vrai, je vais toujours utiliser les mêmes étapes, ce sont juste les résultats (redirections, messages de succès/erreurs) qui vont changer. Et si donc je créais un scénario, avec les entrées et les sorties dans un tableau. Ca serait concis et clair, non? Faisons le:

Un peu de vinaigrette...

Pour bien comprendre la puissance de Cucumber, il serait intéressant de faire un intermède dans cet article gastronomique et orienté expression des besoins par les tests, pour parler un tout petit peu technique et convention.

Il faut savoir que Cuke embarque un certain nombre de "fixtures" déjà développées. Une fixture, c'est juste le code de liaison entre le test de recette écrit par le métier et l'application testée (explication sur l'excellent article de Christian).

Qu'est ce que cela signifie? De façon tout à fait pratique, cela signifie que si l'AMOA respecte certaines conventions d'écriture (ne commencez pas à hurler), le développeur n'aura AUCUNE fixture à écrire. Exactement. Zéro, nada. Testé et approuvé par votre serviteur lui même.

Alors oui, cela va à l'encontre du premier chapitre, un peu, dans lequel on sent que l'AMOA veut absolument avoir le contrôle de la mise en forme des spécifications par les tests. Mais les règles sont peu nombreuses et couvrent un éventail assez impressionnant de cas. Attention cependant, ces fixtures sont développées pour la locale English. En d'autres termes, l'idéal serait que les développeurs réutilisent tout simplement le contenu des fixtures pré développées en renommant les étapes en français (L'article de Rémy Christophe traite du sujet).

On mélange et on fait ressortir les couleurs

Parlons maintenant un peu d'organisation des tests.

Cucumber gère un système de tags. De cette façon, chaque fonctionnalité peut avoir une étiquette, et il est donc possible de lancer uniquement certains tags. Pourquoi faire me direz vous?

Un exemple simple. Dans le cadre des tests au fil de l'eau, il arrive souvent que l'AMOA et les développeurs vérifient l'état des tests de recette en cours d'itération. Parfois, ces tests prennent un certain temps, en particulier quand dans certains cas, on commence à faire des appels massifs en BDD (migrations de référentiels par exemple). Dans ce cas là, on peut facilement imaginer un tag @integration_continue et un tag @local. Ainsi, en permanence le tag @local sera exécuté. De la même façon, les 2 tags seront lancées sur la PIC (plateforme d'intégration continue). Gain de temps et délégation d'une partie de la charge à l'intégration continue. On peut également imaginer de ne tester que certaines MMF (minimum marketable features) correspondant à des incréments définis dans notre road map, voire un peu plus finement plusieurs fonctionnalités sémantiquement similaires (la gestion utilisateur par exemple: registration, login, gestion profil...).

Cela autorise une certaine souplesse dans l'exécution des tests et permet également d'avoir une vision claire de l'avancée du développement produit.

Et au final alors... c'est bon ou pas?

Cucmber reste un peu limité pour le moment sur certains aspects, et souffre sur certains point par rapport à la concurrence. En effet les tests cucumber sont par exemple exclusivement écrits à l'intérieur du projet en lui même, et il n'existe aucun plugin pour un wiki, ce qui est quand même moins agréable pour l'AMOA. Avis au développeurs motivés donc!

Cependant, pour être tout à fait honnête, Cucumber n'en est qu'a la version 0.4.X, et possède déjà un certain nombre de fonctionnalités assez bluffantes pour les maîtrises d'ouvrage. Le langage naturel et son expressivité, le fait qu'il vienne avec tout un tas de fixtures pré codées, et d'autres petites choses font de cet outil un outil sucré. Oui oui, sucré.

Si vous voulez voir certaines des fonctionnalités de cet article développées en rails, vous pouvez jeter un coup d'oeil ici.