Le triple AAA et le GWT sont en fait exactement la même chose à un niveau différents pour rendre les tests indépendants et précis. C'est pourquoi il faut limiter le BDD et l'usage du Gherkin à des test de User Stories et non pour des tests de bout en bout qui couvrent des flows utilisateurs plus larges avec différents états (https://martinfowler.com/bliki/UserJourneyTest.html) ou alors il faut abstraire encore plus le métier.
Parmi les autres principes du BDD on retrouve aussi la notion d'ubiquitous language inspirée du Domain Driven Development et des principes du Clean Coding qui veut qu'on retrouve le langage du domaine jusqu'au niveau du code
Pour revenir au Gherkin, avec Playwright par exemple, même en partant de fichier .feature, je maintiens mes tests lisibles en recourant à la notion de step. Je documente ainsi mes tests sans forcément maintenir le couplage fort entre le fichier .feature et mon code de glue. C'est beaucoup moins contraignant car ca évite de batailler avec les World de Cucumber.js. En plus, je conserve les avantages du runner de PW. C'est un bon compromis lorsque tu n'as pas de contraintes fortes sur la vérification des règles métier.
[^] # Re: Réflexions sur le journal et le projet mis en lumière
Posté par El Titi . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 4.
Le triple AAA et le GWT sont en fait exactement la même chose à un niveau différents pour rendre les tests indépendants et précis. C'est pourquoi il faut limiter le BDD et l'usage du Gherkin à des test de User Stories et non pour des tests de bout en bout qui couvrent des flows utilisateurs plus larges avec différents états (https://martinfowler.com/bliki/UserJourneyTest.html) ou alors il faut abstraire encore plus le métier.
Le blog que j'ai déjà pointé illustre bien cette problématique: https://automationpanda.com/2018/02/03/are-gherkin-scenarios-with-multiple-when-then-pairs-okay/
Parmi les autres principes du BDD on retrouve aussi la notion d'ubiquitous language inspirée du Domain Driven Development et des principes du Clean Coding qui veut qu'on retrouve le langage du domaine jusqu'au niveau du code
Si tu es intéressé par tous les moyens de documenter ton code par le bas et ainsi éviter la désynchronisation entre les 2, couvrant d'autres aspects que le BDD et toutes les techniques à mettre en oeuvre, je te recommande cet ouvrage très intéressant: https://www.google.fr/books/edition/Living_Documentation/8_6ZDwAAQBAJ?hl=en&gbpv=1&printsec=frontcover
Pour revenir au Gherkin, avec Playwright par exemple, même en partant de fichier .feature, je maintiens mes tests lisibles en recourant à la notion de step. Je documente ainsi mes tests sans forcément maintenir le couplage fort entre le fichier .feature et mon code de glue. C'est beaucoup moins contraignant car ca évite de batailler avec les World de Cucumber.js. En plus, je conserve les avantages du runner de PW. C'est un bon compromis lorsque tu n'as pas de contraintes fortes sur la vérification des règles métier.
Dans le monde Java, pour les TU tu peux adopter aussi ce style avec Kotest par exemple :
https://kotest.io/docs/framework/testing-styles.html#behavior-spec
Ca me manque avec JUnit.