On est d'accord, mais la proximité de GWT avec Gherkin donne plus l'impression qu'il s'agit d'un gherkin du pauvre. Dis autrement ça tend à donner l'impression qu'on ferait du gherkin si on pouvait alors que c'est pas forcément le lieu.
Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:
Le BDD n'est qu'une extension du TDD (certains diraient que c'est le TDD appliqué de la bonne manière: outside in).
Avec le TDD, le AAA est un pattern pour écrire des test unitaires atomiques et répétables avec les 3 composantes d'un bon test.
Aucune différence entre commenter ton code :
// Arrange
...
// Act
...
// Assert
... et
// Given
...
// When
...
// Then
... ou d'utiliser un framework avec du sucre syntaxique pour ce faire (au delta du reporting près)
Tous ces frameworks sont avant tous destinés aux TUs même si on les appellent frameworks BDD par opposition aux frameworks xUnit. Tout comme le sont les frameworks type Jasmine ou le style describe de Kotest qui aboutissent au même résultat sans se conformer à la syntaxe GWT.
Les frameworks dits "purs BDD" s'attachent à séparer la spécification sous forme textuelle comme base de discussion de l'implémentation comme: Cucumber, Concordion, Fitnesse, ...
L'avantage de ces derniers, outre l'aspect collaboration sur les spec est de permettre de réutiliser le lexique par des non techniciens pour composer de nouveaux scénarios. Le gros inconvénient étant leur lourdeur (maintenance du lexique, partage des états entre les steps, ...). Même si la démarche BDD est continue au travers des niveaux de tests, elle nécessite des outils différents. D'où leur usage avec circonspection.
Pour ce qui est du DDD, je voulais simplement rappeler le principe de réutilisation du vocabulaire du domaine à tous les niveaux, y compris dans le code. Les considérations de design et d'architecture relèvent d'un autre débat qui sort un peu du périmètre de la discussion.
Sinon, oui Spock est un bon framework dans le même style mais le Groovy n'a plus guère le vent en poupe aujourd'hui.
[^] # 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é à 3.
Je ne suis pas certain de bien comprendre ta remarque je vais donc repréciser ce que je voulais expliquer:
Le BDD n'est qu'une extension du TDD (certains diraient que c'est le TDD appliqué de la bonne manière: outside in).
Avec le TDD, le AAA est un pattern pour écrire des test unitaires atomiques et répétables avec les 3 composantes d'un bon test.
Aucune différence entre commenter ton code :
et// Arrange
...
// Act
...
// Assert
...
ou d'utiliser un framework avec du sucre syntaxique pour ce faire (au delta du reporting près)// Given
...
// When
...
// Then
...
Tous ces frameworks sont avant tous destinés aux TUs même si on les appellent frameworks BDD par opposition aux frameworks xUnit. Tout comme le sont les frameworks type Jasmine ou le style describe de Kotest qui aboutissent au même résultat sans se conformer à la syntaxe GWT.
Les frameworks dits "purs BDD" s'attachent à séparer la spécification sous forme textuelle comme base de discussion de l'implémentation comme: Cucumber, Concordion, Fitnesse, ...
L'avantage de ces derniers, outre l'aspect collaboration sur les spec est de permettre de réutiliser le lexique par des non techniciens pour composer de nouveaux scénarios. Le gros inconvénient étant leur lourdeur (maintenance du lexique, partage des états entre les steps, ...). Même si la démarche BDD est continue au travers des niveaux de tests, elle nécessite des outils différents. D'où leur usage avec circonspection.
Pour ce qui est du DDD, je voulais simplement rappeler le principe de réutilisation du vocabulaire du domaine à tous les niveaux, y compris dans le code. Les considérations de design et d'architecture relèvent d'un autre débat qui sort un peu du périmètre de la discussion.
Sinon, oui Spock est un bon framework dans le même style mais le Groovy n'a plus guère le vent en poupe aujourd'hui.