Comparatif outils de rédaction de spécifications exécutables

Comparatif outils de rédaction de spécifications exécutables

Pour les démarches type ATDD, BDD, SpecByExample

This article is also available in English.

J’adore la démarche des Spécifications Exécutables ! Alors voici un comparatif des principaux outils utilisés dans cette démarche.

Je vous propose de mettre en lice :

• FitNesse
• Cucumber (et ses variantes)
• Robot Framework
• Concordion
• Gauge

Mise à jour 1 : Hiptest me précise dans les commentaires que leur solution est gratuite pour les startups, et qu’elle supporte Robot Framework et Gauge en plus de Cucumber/Gherkin. Intéressant !

Mise à jour 2 : Je n’avais pas remarqué que Gauge supporte désormais d’autres langages que Java et C#. J’ai mis à jour l’article en conséquence. Preuve que Gauge continue de gagner en maturité ! Vivement que je trouve un projet pour tester cet outil 😁

Mise à jour 3 : Traduction de l’article en anglais.

Attention : l’implication des fonctionnels

À noter : je parle bien de la démarche où ce sont les fonctionnels qui rédigent les tests. Et pas les développeurs.

C’est pourquoi je ne parle pas de tous ces outils qui prennent une approche beaucoup plus simple en restant beaucoup plus proche du langage de programmation sous-jacent. Je range par exemple dans cette catégorie Jasmine (JavaScript), Spock (Java) et Codeception (PHP). Mécaniquement, en étant plus proche des environnements de développement, ces outils sont également moins accessibles aux non-développeurs.

Si par contre vous n’arrivez pas à impliquer les fonctionnels dans la démarche de rédaction des tests/spécifications exécutables, alors n’hésitez pas à vous orienter plutôt vers ces outils plus légers !

Ne vous embêtez pas avec une usine à gaz si les seuls utilisateurs sont des développeurs…

Allez, maintenant que ça c’est dit on y va !

TL;DR

Globalement, tous les outils savent tout faire : ils savent gérer tous les types de scenario, on arrive toujours à s’en sortir pour exprimer les concepts. Bien entendu, ils s’en sortiront plus ou moins bien selon vos typologies de besoins, vous galèrerez plus ou moins, votre test sera plus ou moins lisible, et ils nécessiteront plus ou moins de code derrière. Mais vous ne serez jamais bloqué face à l’impossible.

Par contre, Cucumber est le plus facile d’accès pour les non-techniques, et est disponible partout. Ces deux arguments pèsent largement en sa faveur et c’est globalement un très bon choix par défaut.

Continuez de lire si vous voulez faire un choix plus éclairé en fonction de votre contexte !

FitNesse

FitNesse, c’est un vieux de la vieille maintenant. Un descendant de Fit, pionnier dans ces démarches de spécification par l’exemple et de pilotage des développements par des tests d’acceptation.

Sa plus grande particularité, c’est de prendre la forme d’un Wiki, un site web directement accessible avec formatage de son contenu, et librement modifiable depuis cette même interface.

Les + :

• Un outil établi et connu : allez sur leur mailling-list et vous aurez des réponses ! Les GitHub sont également maintenus et continuent de bouger malgré l’âge de l’outil. FitNesse est utilisé dans pas mal d’entreprises. Vous trouverez aussi des bouquins dessus !
• Purement communautaire : il n’y a aucune entreprise derrière FitNesse ; ce n’est pas un produit créé par une entreprise qu’elle aurait partagé en open-source. La direction que prendra l’outil ne sera pas liée au business model d’une entreprise en particulier.
• Installation triviale : java -jar fitnesse.jar et c’est parti…
• Wiki intégré, format doc directement accessible : pas besoin d’outil pour éditer, pas de lien à faire entre les fichiers et leur rendu…
• Runner disponible pour beaucoup de plate-formes : interfaçage via des protocoles spécifiques (FIT et SLIM).
• Les plus belles tables de décision : vraiment, ça en jette ! On dirait exactement ce qu’écriraient les fonctionnels dans une feuille Excel.
• Un endroit où écrire du beau blabla : les fonctionnels peuvent s’étendre et détailler le contexte de la règle métier, sans contrainte ! Ils peuvent insérer des images, formater le texte…

Les − :

• Un outil vieillot : l’outil est vénérable, et ça se sent. Le protocole d’interfaçage avec le serveur de code (FIT ou SLIM) est clairement discutable. C’est très compliqué d’adresser plusieurs produits avec des technologies différentes dans la même base de test. Et quand il y a une erreur, pas toujours évident de bien comprendre ce qui est allé de travers.
• Langage incohérent : il y a plusieurs types de tables pour différents types de tests, et chaque table a en fait sa propre syntaxe, ses propres subtilités de fonctionnement. Ces différences de comportement sont rarement justifiées.
• Scenarii workflow imbitables : parmis les différents types de tests possibles, les tests de type workflow (un enchainement d’étapes, d’actions et de vérifications) sont particulièrement difficiles à lire et à maintenir.
• Concepts contre-intuitifs : vous écrivez du test dans un éditeur du Wiki, et le Wiki va le transformer en HTML. Le test, ce n’est pas le texte que vous avez écrit mais bien le HTML généré. Ainsi, si vous écrivez une URL, celle-ci sera rendue cliquable par le Wiki ; mais du coup dans un test la chaine de caractère n’est pas votre URL mais une balise <a> menant à votre URL…
• Utilisation du Wiki obligatoire, rapports de test et rédaction pas « text-friendly » : l’utilisation de FitNesse en dehors de son Wiki n’est pas naturelle ni pratique. C’est un point négatif pour les développeurs, à moins d’utiliser une extension pour FitNesse dans leur IDE — extension qui n’est pas disponible pour tous les langages et tous les IDE. De même le versionnement n’est pas naturel puisque ce sont les fichiers qu’on versionne ; les options de versionning intégrées au Wiki n’étant pas idéales.
• Pas d’éditeur avancé pour les non-dev : si les développeurs peuvent éventuellement avoir accès à une intégration à leur IDE, les non-développeurs n’ont pas d’autre option que de passer par le Wiki, qui reste un éditeur très rudimentaire. Comprendre : il n’y a pas de completion.

En conclusion :

Outil pas mal pour sa facilité d’installation et de mise en place.

Attention tout de même à ne pas trop se focaliser sur ce point ; ce qui compte c’est l’effort total pour arriver à une intégration continue complète et fonctionnelle.

Néanmoins, face à un public nécessitant un POC avant d’être convaincu, FitNesse permettra la mise en place du POC en 1 heure ou 2 seulement, rédaction et exécution du premier test inclus.

Cucumber

Tout le monde connait Cucumber ! Maintenu par l’entreprise du même nom (Cucumber Ltd.), c’est réellement cet outil qui a imposé le BDD ou Behavior-Driven Development, et l’utilisation du Given-When-Then pour l’expliquer et l’illustrer.

Cucumber, c’est aussi plusieurs noms en fonction de la plate-forme. Ainsi sous PHP il s’appelle Behat et sous C#/.NET il s’appelle SpecFlow.

Mais surtout il y a le langage utilisé pour formuler les tests, qui s’appelle Gherkin et qui est utilisé très largement en dehors de Cucumber. Cucumber étant la solution de référence pour exécuter du Gherkin.

Les + :

• Multi-plate-forme au niveau source avec Gherkin : si vous avez plusieurs plate-formes à maintenir avec les mêmes règles métier, vous pourrez spécifier un unique test qui sera lancé par deux stacks différentes. Vous ne pourrez pas mélanger les deux stacks dans le même test mais en pratique c’est rarement nécessaire.
• Runner disponible sur quasiment tous les environnements, directement intégré : par exemple l’intégration de Behat à un projet PHP se fait à coup de quelques rapides composer. Des extensions sont proposées pour étendre les fonctionnalités proposées. Sur GitHub, on trouvera des intégrations quasiment pour n’importe quel contexte.
• Prise en main simple, pas d’outil nécessaire à la rédaction : Cucumber, ou plutôt Gherkin, c’est juste quelques mots-clés. La rédaction du premier test se fait avec n’importe quel éditeur texte : on ne commence pas par apprendre un outil nécessaire à la rédaction.
• Des contraintes de rédaction qui en font un excellent outil pédagogique : si le langage est très simple avec seulement quelques mots clés, par contre il impose de fortes contraintes sur la forme. On a peu de liberté dans la rédaction des tests. Si cela peut être vu comme un inconvénient pour un utilisateur chevronné, c’est en fait un atout majeur pour un novice, car cela va le forcer à se poser les bonnes questions et à s’approprier une bonne démarche de rédaction des tests. Ce carcan de rédaction sert donc surtout de guide.
• Langage localisable en français : et dans quasiment toutes les langues en fait. Vous vous en fichez peut-être, mais pas mal de boîte sont encore très franco-françaises et ont des fonctionnels qui n’envisagent pas de devoir rédiger leurs specs autrement qu’en français. D’une certaine manière c’est logique : si votre domaine métier ou votre marché est fortement lié à une culture locale, cela fait du sens de décrire le produit dans la langue correspondante. Au final, cet élément participe à faciliter la prise en main du langage par les fonctionnels.
• La référence dans le domaine — « Given-When-Then » est utilisé par tout le monde : les livres sur Cucumber et son écosystèmes sont légion, et je ne parle même pas de ceux qui utilisent le formalisme de Gherkin sans le nommer. La communauté est très large et très active. Quelle que soit votre question, vous trouverez la réponse.

Les − :

• Pas vraiment d’IDE qui s’adresse aux fonctionnels : les développeurs disposent de belles intégrations dans leurs IDE et ça leur facilite bien la vie. Par contre c’est plutôt le désert côté fonctionnel. Certains produits commerciaux semblent proposer quelque chose, comme HipTest qui intègre le Gherkin dans JIRA avec une completion des steps déjà définis, ou Cucumber Pro qui a l’air très prometteur mais est toujours en beta fermée. Hiptest me précise que leur solution est gratuite pour les startups.
• La coloration syntaxique ne marche qu’en anglais : à défaut d’un IDE avec completion, on trouve assez facilement des extensions qui vont faire de la coloration syntaxique pour votre éditeur préféré : SublimeText, Notepad++, Atom… Mais cette coloration syntaxique ne fonctionnera probablement pas si vous localisez les mots-clés ; vous n’aurez la couleur qu’avec l’anglais et son Given-When-Then.
• Langage restreint et contraignant : cité dans les +, le langage est restreint et contraignant. Cela devient gênant lorsque le projet devient très mature et que l’on commence à vouloir réutiliser beaucoup de choses un peu partout. C’est également un soucis lorsque l’outil est détourné pour piloter des tests automatiques et non pas pour faire des tests d’acceptation. Ce point est discutable puisqu’on détourne l’usage du produit mais c’est néanmoins un reproche qu’on peut souvent lire étant donné la popularité de l’outil : les dérives sont inévitables.
• Plus (+) de code de lien : comparativement aux autres outils, c’est peut-être celui qui demande d’écrire le plus de code de lien pour rendre exécutables les spécifications. Le but étant de faciliter les échanges entre techniques et fonctionnels, cela ne devrait pas être un critère de décision essentiel.

En conclusion :

Vous ne pouvez pas vraiment vous tromper avec Cucumber. Ce ne sera peut-être pas le meilleur choix, mais ce ne sera pas un mauvais choix.

L’une des plus grosses difficultés dans la démarche des spécifications exécutables, c’est de les faire rédiger par les fonctionnels eux-mêmes. De fait, la facilité de prise en main de Cucumber est un atout majeur. La possibilité de localiser le langage permet de faciliter encore un peu plus cette prise en main.

Le néophyte va rencontrer toutes sortes de problèmes et n’arrivera pas à écrire ce qu’il a spontanément en tête. Justement, ces difficultés vont le forcer à se poser les bonnes questions. Il va par exemple devoir comprendre pourquoi faire des petits tests, qui ne testent qu’un seul et unique concept à la fois, sont mieux que des gros tests qui testent tout en une seule fois.

Et pour ne rien gâcher, Cucumber est disponible partout ! Vous pouvez même imaginer rédiger un cas de test qui se lancera sur tous vos produits malgré des technologies différentes.

Robot Framework

Robot Framework est peu avenant de prime abord : très sobre, on se demande si l’outil a réellement des utilisateurs.

Et bien oui, il a des utilisateurs ! C’est un véritable outil, fonctionnel, très bien fichu, et avec un noyau dur d’utilisateurs, une communauté restreinte mais très active. Remercions Pekka Klärck pour avoir créé cet outil. Il est toujours très actif dans toutes les communautés et les évènements autour de Robot Framework.

L’outil tire ses origines des pays nordiques (notamment la Finlande) et cela se retrouve dans les entreprises qui utilisent et supportent activement Robot Framework. La plus notable étant peut-être Nokia !

Ce qui va distinguer Robot Framework ? Sa polyvalence et sa capacité à savoir faire beaucoup de choses, out-of-the-box.

Les + :

• Langage très complet, puissant, régulier : le langage de description des cas de test Robot Framework est très puissant, et surtout régulier. On exécute ainsi des mots-clés (keywords) qui peuvent eux-même être définis par l’utilisation d’autres mots-clés. À chaque niveau, on peut mettre un timeout, du code de préparation, du code de nettoyage, une documentation, des tags… Par défaut, l’outil est capable de gérer des listes, des dictionnaires, des branchements conditionnels. Des options à utiliser avec modération, mais c’est très confortable de les avoir sous la main !
• Réutilisation des mots-clés, sans limite : je viens d’en parler, les mots-clés peuvent être eux-mêmes défini par l’utilisation d’autres mots-clés. On peut factoriser les mots-clés dans des fichiers qu’on importera dans tous les tests qui en auront besoin. Eux-mêmes peuvent utiliser des mots-clés venant d’autres fichiers, de librairies…
• Nombreuses librairies clé-en-main, ajout en Python ou serveurs de mots-clés dynamiques dans n’importe quel langage : Robot Framework propose d’office beaucoup de librairies, par exemple pour se connecter en SSH. De nombreuses librairies tierces parties sont disponibles. On peut facilement en écrire de nouvelles en Python, on peut même écrire un peu de Python directement dans les tests pour gérer des cas très spécifiques. Ou enfin, on peut se brancher sur n’importe quel produit via un serveur de mots-clés dynamique, dont l’implémentation repose sur XML-RPC, un protocole standard et éprouvé.
• Multi-plate-forme avec possibilité de mélanger les technos dans le même test : c’est, à ma connaissance, le seul outil disposant d’une architecture permettant de mélanger plusieurs technos dans le même test. Concrètement, on peut importer plusieurs fois la même librairie sous des noms différents. On peut ainsi se connecter sur plusieurs serveurs de mots-clés dynamiques en même temps, chaque serveur pouvant adresser un produit différent, et pas forcément dans la même techno.
• Nombreux outils associés, matures et complets : Robot Framework ce n’est pas seulement un langage. Il y a un runner de tests bien entendu mais également d’autres outils pour générer des rapports, ou encore un runner lançant les tests en parallèle. Tous ces outils proposent énormément d’options et sont très bien documentées. On sent que ces outils ont été bien pensés ; vous arriverez forcément à vos fins lorsque vous mettrez en place votre intégration continue.
• Des logs d’exécution complets : les rapports de test et les logs d’exécution sont comme toujours d’apparence sobres, mais sont surtout très complets. Vous pourrez ainsi voir le déroulé de chaque cas de test, avec le détail par mot-clé appelé, lui-même décomposé en chacun des mots-clés le composants. Si des logs sont affichés lors de l’exécution d’un mot-clé, ceux-ci sont rattachés au mot-clé correspondant. D’un point de vue compréhension et debug de ce qu’il s’est passé, c’est exemplaire.
• Plusieurs vrais IDE non restreints aux développeurs : point assez rare pour être noté, plusieurs IDE stand-alone existent pour rédiger des cas de test Robot Framework sans passer par l’utilisation d’un IDE de développeur. Quel bonheur que de pouvoir utiliser la completion pour retrouver les mots-clés utilisés dans d’autres tests ! Si RIDE est maintenant un peu vieillot, RED est sur la pente montante et propose par exemple de débugguer les cas de test en faisant de l’évaluation étape par étape au niveau des cas de test Robot Framework. Rien que ça !
• Liberté du format de test : workflow, table de décision, Given-When-Then… Quel que soit le type de test, vous pouvez le faire dans Robot Framework avec un résultat plutôt lisible.

Les − :

• Langage complexe, difficile d’accès aux non-techniques : le cœur des cas de test est en soi plutôt lisible et accessible, cependant il faut voir tout ce qui entoure ce cas de test. On parle de variables, d’imports, de librairies, de mots-clés, de fichiers. Autant de concepts qui sont étrangers des non-techniques. Dans la même veine, les IDE peuvent être relativement complexes à prendre en main puisqu’ils permettent de faire beaucoup de choses.
• IDE parfois buggé, certains use-cases du langage non supportés sans édition textuelle : RIDE, l’IDE historique de Robot Framework, est truffé de petits bugs. Rien de dramatique, mais en usage prolongé on tombera tôt ou tard dessus et c’est parfois énervant. Et certaines fonctionnalités du langage ne sont pas accessibles depuis l’IDE : on est alors obligé de passer en mode texte pour faire la modification, le comble ! De l’autre côté, RED est un IDE beaucoup plus récent et moderne, mais cela ne fait pas longtemps qu’il est complet.
• Serveurs de mots-clés pas disponibles sur tous les environnements : le protocole pour communiquer avec les serveurs de mots-clés dynamiques a l’intérêt de reposer sur XML-RPC, qui est un protocole standard et éprouvé. Malgré tout, l’effort d’implanter un tel serveur de mots-clés dynamiques n’a pas été fait pour tous les environnements. Si c’est votre cas, vous préférerez probablement passer à côté de Robot Framework plutôt que de vous lancer dans l’implantation de cette brique manquante, même si ce n’est pas très dur : je sais de quoi je parle pour avoir repris intégralement celui pour PHP.
• Logs d’exécution durs à utiliser comme documentation de référence : les rapports de tests d’une spécification exécutable sont sensés représenter la vérité absolue — voici exactement le comportement du produit. Les rapports de Robot Framework, s’ils sont complets, noient par contre un peu dans la masse l’information d’origine, c’est à dire la description du comportement. C’est un peu rater l’enjeu fondamental de la démarche des spécifications exécutables en se focalisant trop sur les mécanismes permettant l’exécution.

En conclusion :

La plupart des avantages et inconvénients de Robot Framework sont directement liés :

• Super logs d’exécution car très complets facilitant les investigations et le debug, mais du coup mise en péril de la lisibilité des spécifications elles-mêmes
• Langage très bien conçu, puissant et complet, mais du coup compliqué à prendre en main
• De véritables IDE sont disponibles et sont un réel bonheur à utiliser, mais mécaniquement ce sont des outils autrement plus complexes à prendre en main qu’un simple éditeur de texte

Ce qui nous amène à discuter du public à qui s’adresse cet outil. Pas adapté à des fonctionnels non-techniques, il fera par contre la joie des testeurs qui ont généralement l’habitude de manipuler des outils complexes — quand il ne s’agit pas de coder ! Ces mêmes testeurs qui peuvent se sentir frustrés par d’autres outils comme Cucumber qui imposent des contraintes et des limitations, seront comblés par l’utilisation de Robot Framework.

Concordion

Comme FitNesse, Concordion est un descendant de Fit. Mais la voie qui a été choisie par Concordion est très différente de celle prise par FitNesse : là, le focus est véritablement sur la construction d’une spécification, c’est à dire un doc qui ressemble au maximum aux documents habituels — avec le côté exécutable en plus, bien entendu !

Je n’ai malheureusement pas eu l’occasion d’essayer en pratique, sur un vrai projet, ce que pouvait donner Concordion. Mes analyses sont donc drastiquement réduites. N’hésitez pas à me corriger ou à me compléter en commentaire !

Les + :

• Littéralement une spec qu’on peut exécuter : Concordion c’est l’outil dont la formulation se rapproche le plus d’une spécification à l’ancienne, sauf que bien sûr elle est vivante et on peut l’exécuter. Cela peut sonner comme un défaut (mais si rappelez-vous, le cycle en V c’est le mal…) mais c’est véritablement sa force. Imaginez bien que dans certains domaines, les contraintes de législation et de régulation sont très fortes et on ne peut pas sortir un produit sans un document montrant bien que le produit respecte les normes en vigueur. D’un côté l’enjeu est d’avoir un document dont la cohérence avec le produit est garantie — c’est tout l’intérêt de la démarche des spécifications exécutables. Mais d’un autre côté, l’enjeu est également d’avoir un document lisible par des personnes complètement externes au projet, qui vont tamponner le document pour dire que le produit respecte bien les normes. Aucun compromis sur la lisibilité n’est donc permis.
• Belle intégration d’images et autres éléments de description d’une spec : pour aller toujours plus loin dans cette démarche de spécification, on peut intégrer des images et d’autres éléments. Ces intégrations sont très bien faites, toujours avec un focus sur le rendu et la lisibilité avant tout.

Les − :

• Frontière entre technique et fonctionnel tirant sur la technique : étant donné le focus sur la rédaction côté fonctionnel, mécaniquement le code derrière rendant exécutable ces spécifications va devoir aller plus loin qu’avec d’autres outils. Les concepts de test sont moins présent côté fonctionnel, c’est donc à la partie technique de les implanter.
• Plate-formes majeures uniquement (Java, C#, Python, Ruby) : à ma connaissance, Concordion n’est disponible que sur Java, C#, Python et Ruby.

En conclusion :

Comme je l’ai expliqué, certains domaines ont des contraintes très fortes sur les législations que doivent respecter leur produit. Potentiellement, le président de la société va imposer sa signature en bas d’un document jurant que le produit fait bien ce qu’on lui demande. Dans ces situations, Concordion est le bon outil car son focus premier est sur une formulation familière des spécifications exécutables.

Gauge

Gauge est l’outil le plus récent de la liste et est maintenu par ThoughtWorks. Il essaie de reprendre les bonnes idées des outils existants tout en fournissant un environnement d’éxécution efficace et productif.

L’outil est encore jeune, et évolue tranquillement. La communauté n’est pas encore très large mais est bien existante, portée par ThoughtWorks.

Je n’ai malheureusement pas eu l’occasion d’essayer en pratique, sur un vrai projet, ce que pouvait donner Gauge. Mes analyses sont donc drastiquement réduites. N’hésitez pas à me corriger ou à me compléter en commentaire !

Les + :

• Rédaction en MarkDown, écosystème MarkDown pour le formatage et l’édition : on trouve à la pelle des éditeurs MarkDown et des générateurs de document à partir de MarkDown.
• Par ThoughtWorks ! En soi, une garantie de la qualité de ce produit ainsi que de son pragmatisme.
• Plein de bonnes idées, essaie de reprendre le meilleur de ses aînés : c’est l’intérêt de sortir une nouvelle solution, on essaie d’en garder le meilleur et d’améliorer ce qui était moins bien. Par exemple, la notion de lancer les tests en parallèle est directement intégrée dans Gauge alors qu’on sent bien que pour les autres outils cela a été un ajout, motivé après coup.

Les − :

• Java / C# / Ruby / JavaScript / Python / Golang : les plate-formes supportées deviennent de plus en plus nombreuses.
• Relativement jeune : l’outil reste jeune et s’il est utilisable, on peut certainement trouver des fonctionnalités manquantes ou des choses mal fichues. On peut espérer que ces éléments seront corrigés avec le gain en maturité de l’outil.

En conclusion :

Un outil très prometteur qui mériterait d’être essayé ! À condition que vous utilisiez une des plate-formes supportées.

Le gagnant du match

C’est Cucumber bien entendu !

• Mettre le pied à l’étrier des fonctionnels : le plus facile à prendre en main de prime abord, simplicité du langage mais aussi pas besoin d’éditeur spécifique. De plus le langage impose des contraintes qui vont guider le néophyte dans son apprentissage.
• Dispo quelle que soit votre techno
• Multi-techno au niveau de Gherkin : c’est un use-case courant d’avoir plusieurs produits avec les mêmes règles métiers. On peut vérifier le même cas de test sur ces différents produits en utilisant des solutions techniques différentes. Au pire, on peut même se passer de Cucumber mais tout de même garder le même cas de test en Gherkin ; par exemple en utilisant Calabash.
• Enorme communauté : quelle que soit votre problème, quelqu’un sera déjà passé par là !
• Beaucoup d’outils dérivés : un écosystème large et actif, plein de bonnes choses pour vous faciliter la vie.
• La référence ! Vous ne serez pas perdu en lisant la littérature…

Vous avez aimé cet article ? Cliquez sur le cœur ♡ pour m’encourager !

Et abonnez-vous à moi via le bouton Follow pour être notifié de mes nouveaux articles. J’en rédige au moins un par semaine.