Peut-on faire du BDD sans Gherkin et Cucumber ?

Talk pour un format plutôt long (40-45 min) Tout public/profils : dev, QA, product

Est-ce que vous aussi vous avez déjà été séduits par l’apparente facilité du langage Gherkin ? Est-ce que vous aussi vous l’avez essayé sur un projet (personnel ou professionnel) ? Et finalement, est-ce que vous avez rejoint le groupe des quelques amoureux du BDD ou celui de ses nombreux haters ???

On dit souvent que si les gens n’aiment pas le BDD, c’est parce qu’ils le pratiquent mal. C’est vrai… partiellement seulement. Effectivement, maîtriser les outils (notamment la rédaction des scénarios Gherkin) nécessite une vraie montée en compétence qui est souvent négligée. Mais le problème vient surtout de la confusion entre “pratiquer le BDD” et “utiliser les outils du BDD” (i.e. Gherkin/Cucumber).

Puisque la difficulté dans la pratique du BDD ce sont ses outils, est-ce qu’il serait possible de pratiquer le BDD sans eux ?

Buts du talk :

• montrer que l’essence du BDD est dans la collaboration et pourquoi c’est la seule chose qui compte,
• décorreler le BDD de ses outils (Gherkin/Cucumber) et proposer des alternatives,
• rappeler le seul vrai intérêt de Gherkin/Cucumber : avoir une documentation toujours à jour.

Plan / idées clés : 1- Le BDD : une évolution du TDD Retour sur les origines du BDD et de ses outils. Mêmes logiques et méthodo que TDD, simplement ramener du sens (métier) dans les tests.

2- La collaboration au centre (indispensable)

• sens métier = PO => collaboration
• objectif : être alignés, car le produit qui sort n’est pas ce qu’a présenté le PO, mais ce que le dev a compris.
• tuer les incompréhensions : exemples et ubiquitous language.
• co-créer la spec

Pratiques :

• 3 amigos
• example mapping

3- Automatiser ses tests : pas besoin de Gherkin (ni de Cucumber et cie) Automatisation = filet de sécurité contre les régressions inaperçues, sérénité.

• une même règle métier peut être automatisée à différents niveaux : choisir intelligemment.

4- Quel intérêt d’utiliser Gherkin et Cucumber ?

• seul intérêt : documentation vivante. Or cet aspect est très souvent oublié/ignoré. Et sans l’effort de monter en compétence sur la rédaction des scénarios Gherkin, cet intérêt est de toutes façons manqué. -> éléments clés -> conseils : ne pas exprimer ses scénarios avec des détails d’implémentation (// bonne pratique : BRIEF)

5- Mise en perspective

• specs par l’exemple
• autres outils existants (FitNesse, Concordion, …)
• Avec l’IA : regain d’importance de l’essence du BDD (spécifier clairement et aligner)