Cucumber

Les tests, c’est pas juste une histoire de devs.

Y’a aussi les Product Owners, les testeurs, les business analysts…
Et chacun a sa manière de voir les choses.

Résultat ?

• ❌ Les devs écrivent des tests unitaires… mais personne d’autre ne les comprend.
• ❌ Les PO rédigent des specs… mais les devs les interprètent différemment.
• ❌ Les testeurs exécutent des scénarios… mais ils ne couvrent pas toujours ce que les PO avaient en tête.

Bref, un bordel de communication.

Et puis, un jour, Dan North (un consultant agile) se demande :
“Et si on écrivait les tests dans un langage que tout le monde comprend ?”

L’idée paraît simple, mais elle va changer la façon dont on conçoit les tests fonctionnels.

C’est comme ça que naît Cucumber en 2008.

• ✅ Un framework de test basé sur le BDD (Behavior-Driven Development)
• ✅ Un langage naturel, Gherkin, pour écrire les tests sous forme de scénarios
• ✅ Un format que tout le monde peut lire et comprendre

Exemple :

Scenario: Connexion réussie  
Given un utilisateur sur la page de login  
When il entre un identifiant et un mot de passe valides  
Then il accède à son espace personnel

Pas besoin d’être dev pour capter ce que ça fait.
Un PO, un testeur, un client… tout le monde peut relire et valider le test.

Cucumber n’a pas juste apporté un outil.
Il a changé la façon dont on collabore en intégrant les tests dans la discussion métier.

Aujourd’hui, le BDD est devenu une approche clé dans le développement agile,
et Cucumber en est le grand ambassadeur.

➡️ Tout ça, parce qu’un mec en a eu marre des specs floues et des quiproquos.