Note : 4 ; Dans la continuité du « specification by example » de Gojko Adzic, mais bien moins brillant.

Cet ouvrage est dédié à l’écriture de cas de test en Gherkin. Mais pas n’importe comment. Il s’inscrit dans la continuité du « specification by example » de Gojko Adzic qui a d’ailleurs préfacé le livre. En fait d’écriture de cas de test, l’auteur préfère évoquer l’écriture de spécifications (le livre a d’ailleurs changé de titre en cours de route), comme son devancier.

Il y a des variantes à la grammaire Gherkin, l’auteur a fait le choix de cibler celle supportée par Cucumber, bien qu’il fasse allusion à d’autres outils de temps à autre. De toute manière, l’outil n’est pas le propos du texte, ni même l’implémentation des scénarios. C’est bien de leur écriture dont il est question. Pour cet objectif, le texte accuse 250 pages structurées en 11 chapitres réparties sur 2 parties. La première d’entre-elle, regroupe les 6 qui suivent l’introduction et occupe 140 pages.
L’introduction justement, est là pour camper le décor. Il s’agit d’un chapitre plutôt dense, puisqu’il accapare à lui seul 30 pages. L’auteur y développe les définitions qui seront utiles par la suite, les anti-patterns de spécification et surtout sa démarche SBE. Mais que tout cela est verbeux ! Malheureusement, il en sera de même pour la suite.

En ouverture de la 1ère partie « Writing executable specifications with examples », le chapitre 2 évoque sur un peu plus de 20 pages l’articulation entre la couche de spécification et la couche d’automatisation. L’objectif du propos n’est pas franchement clair. J’ai l’impression que l’auteur tente de faire une introduction au ralenti. La véritable introduction est au chapitre 3, elle nécessite 25 pages et introduit tout à fait convenablement la syntaxe et les règles d’écriture qu’y surimpose l’auteur. C’est bien, juste trop volubile par rapport à la quantité d’information délivrée.

Les deux chapitres suivants ont trait au « scenario outline ». D’abord le chapitre 4 nous montre la transition entre une rédaction plein texte et sa formulation sous forme de table. Puis on a droit à des exemples plus sérieux structurés en plusieurs tables. J’avoue que l’auteur maîtrise très bien la structuration pour équilibrer rationalisation et expressivité. Bien joué. C’est exécuté en 15 pages, c’est pour une fois efficace. C’est une démarche d’identification des cas que nous propose ensuite l’auteur au chapitre 5, entre autres avec les différents types de chemins et avec quelques anti-pattern. C’est du bon.

C’est une petite prise de recul qui nous est proposée avec le chapitre 6 qui traite du cycle de vie du SBE. C’est une tentative pour montrer comment le SBE part d’une user story et évolue pour aller jusque dans l’intégration continue. Lecture plaisante, mais je n’en ai pas retiré grand-chose. Le concept de documentation vivante est cher à de nombreux pratiquants du BDD et c’est l’objet du chapitre 7. On sent ici la volonté manifeste de l’auteur de se détacher de Gojko Adzic, d’aller plus loin. Hélas le chapitre est trop stratosphérique à mon goût. Il rate sa cible, mais j’en garde quand même le concept de de MQR : le Minimal Qualified Reader.

La seconde partie de l’ouvrage « managing specification suites » occupe 80 pages et est couvert par 4 chapitres. On ouvre le bal avec le chapitre 8 qui est consacré à l’organisation de scénarios en suites, ce qui nous tient occupé durant une vingtaine de pages. Au-delà de l’organisation en features, le texte évoque l’organisation en user stories, puis en « abilities » et en besoin métiers que l’auteur préfère, allant jusqu’à proposer une organisation physique des fichiers feature. Ce n’est pas géant, mais au moins on a quelque chose. Ce sont un peu moins d’une vingtaine de pages qui sont ensuite consacrées au refactoring des features en abilities. Je vois que le sujet tient à cœur à l’auteur qui décompose le geste par l’exemple. J’avoue que l’approche ne m’a pas du tout convaincue. Le résultat est trop proche pour moi des exigences à l’ancienne.

L’une des promesses du livre est de faire le lien avec le DDD et c’est l’objet des 20 pages du chapitre 10. En fin de compte, on passe vite sur le langage ubiquitaire, probablement parce que l’auteur n’a pas beaucoup de clés à nous partager. Le vrai focus de ce chapitre sont les domaines, sous-domaines voire les domaines génériques ! Parlons alors plus d’UML que de DDD ! Le dernier chapitre s’inscrit dans la continuité en gravitant autour des Bounded Contexts. Au final, celui-ci non plus n’a pas grand-chose à nous apprendre.

Comme je l’ai dit au début, ce livre s’inscrit comme une continuité au texte de Gojko Adzic. Il l’étend efficacement avec des conseils de structuration et surtout d’utilisation des « scenarios outlines ». Il peine largement à apporter de la valeur sur d’autres dimensions : cycle de vie, documentation et larges projets. Bref, pas très convaincant.

Référence complète : Writing Great Specifications – Kamil Nicieja – Manning 2017 – ISBN: 978 1 61729 410 5