BDD était une taxe de coordination. L'IA vient de le retarifier

DEV - 17:55
Gherkin n’a jamais vraiment été un format de test. Il s'agissait d'un protocole de coordination entre des rôles spécialisés. À l’ère de l’IA, où les rôles sont compressés et où la traduction est bon marché, le protocole devient une friction plutôt qu’un levier.

Publié initialement sur tddbuddy.com.

Gherkin n’a jamais vraiment été un format de test. C'était un format de coordination.

La partie test était presque accessoire, un effet secondaire de la nécessité que l'artefact soit exécutable afin qu'il ne puisse pas dériver silencieusement. L'objectif réel était autre chose : amener le produit, l'assurance qualité et l'ingénierie à se mettre d'accord, par écrit, sur ce que le logiciel était censé faire. Le fichier de fonctionnalités était un document de traité entre trois rôles avec des vocabulaires différents, des calendriers différents et des incitations différentes.

Une fois que l’on voit cela, le déclin prend tout son sens. Les traités vivent et meurent avec le coût de coordination qu’ils ont été conçus pour réduire. Lorsque le coût change, le traité devient une cérémonie.

Il s'agit du deuxième article d'un arc en trois parties sur TDD à l'ère agentique. Le premier, "TDD fait déjà BDD, sans le cornichon", a fait le **cas artisanal* au niveau du code : un TDD discipliné avec des constructeurs, des usines et des tests de collaboration pilotés par simulation fournit déjà ce que BDD a promis. Cet article défend le cas de l'organisation. Même les équipes qui avaient légitimement besoin de BDD pour des raisons de coordination voient ce besoin être réévalué. Le troisième, "The Bar for TDD Just Moved", nomme le nouveau niveau attendu et pourquoi le codage agentique le rend non négociable. Si vous payiez la taxe pour des raisons artisanales, le premier message dit stop. Si vous le payiez pour des raisons de coordination, celui-ci indique que la coordination est devenue moins chère. Le troisième indique ce dont vous avez maintenant besoin à sa place.*

Ce que BDD résolvait réellement

Revenons à la raison pour laquelle BDD est apparu. Le problème n’était pas « comment tester le comportement ». TDD y avait déjà répondu. Les TDDers disciplinés écrivaient des tests nommés par scénario, en utilisant un langage omniprésent et encadrant le comportement lors de la mise en œuvre, des années avant l'existence de Cucumber.

Le problème que BDD résolvait réellement était organisationnel.

  • Le produit a rédigé les exigences dans un seul vocabulaire, généralement un document Word ou une épopée Jira.
  • L'assurance qualité a rédigé les critères d'acceptation dans un autre outil, généralement un plan de test dans un outil distinct.
  • L'ingénierie a écrit du code dans un troisième, généralement avec des noms de variables et des types de domaine qui ne correspondaient à aucun des deux autres.

Trois artefacts. Trois vocabulaires. Trois propriétaires. Aucune source de vérité partagée.

Le fichier de fonctionnalités a résolu ce problème en étant un document unique que les trois rôles pouvaient théoriquement lire, modifier et signer. Le format Given-When-Then n’était pas une prose brillante. Il s'agissait d'une grammaire du plus petit dénominateur commun qu'un PM pouvait écrire, qu'un testeur pouvait étendre et qu'un ingénieur pouvait se lier au code.

C'était l'espéranto pour les équipes interfoncti...
[Courte citation de 8% de l'article original]