« Introduction à TDD et BDD » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (3 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 2 : | Ligne 2 : | ||
[[Category: Portail Equipe de développement]] | [[Category: Portail Equipe de développement]] | ||
[[Category: Tests]] | [[Category: Tests]] | ||
[[Catégorie:TDD]] | |||
[[Category: BDD]] | [[Category: BDD]] | ||
[[Catégorie:ATDD]] | |||
Auteur : Cucumber<br/> | Auteur : Cucumber<br/> | ||
Source : [https://cucumber.io/blog/2017/05/15/intro-to-bdd-and-tdd Introduction to TDD and BDD]<br/> | Source : [https://cucumber.io/blog/2017/05/15/intro-to-bdd-and-tdd Introduction to TDD and BDD]<br/> | ||
| Ligne 11 : | Ligne 13 : | ||
Traduction :<br/> | Traduction :<br/> | ||
<br/> | <br/> | ||
[[Fichier:Cukeup-seb.jpg|border]]<br/> | [[Fichier:Cukeup-seb.jpg|border|link=]]<br/> | ||
<br/> | <br/> | ||
Cet article comporte quatre sous-sections. | Cet article comporte quatre sous-sections. | ||
| Ligne 21 : | Ligne 23 : | ||
<br/> | <br/> | ||
==Qu'est-ce que TDD ?== | ==Qu'est-ce que TDD ?== | ||
[[Fichier:Write-failing-test.png|border|800px]]<br/> | [[Fichier:Write-failing-test.png|border|800px|link=]]<br/> | ||
<br/> | <br/> | ||
C'est le cycle TDD classique, popularisé dans le livre de Nat Pryce et Steve Freeman : [https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 Growing Object-Oriented Software, Guided by Tests]. On le décrit généralement comme l'action de "écrire un test qui échoue" puis faire passer le test avec succès et ensuite refactorer le code ; et vous continuez à tourner dans cette boucle. C'est le cycle du TDD, c'est très simple. Il y a trois énoncés simples ; il y a des flèches colorées entre eux. Mais à l'intérieur de ce schéma, il y a beaucoup de complexité ou du moins beaucoup de subtilités.<br/> | C'est le cycle TDD classique, popularisé dans le livre de Nat Pryce et Steve Freeman : [https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627 Growing Object-Oriented Software, Guided by Tests]. On le décrit généralement comme l'action de "écrire un test qui échoue" puis faire passer le test avec succès et ensuite refactorer le code ; et vous continuez à tourner dans cette boucle. C'est le cycle du TDD, c'est très simple. Il y a trois énoncés simples ; il y a des flèches colorées entre eux. Mais à l'intérieur de ce schéma, il y a beaucoup de complexité ou du moins beaucoup de subtilités.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Tdd-bullet-points.png|border|800px]]<br/> | [[Fichier:Tdd-bullet-points.png|border|800px|link=]]<br/> | ||
<br/> | <br/> | ||
Voici une autre façon de le représenter et d'y réfléchir. Bien que "écrire un test qui échoue" soit correct en tant que procédure, cela reste assez déroutant parce que ce n'est pas ce que vous essayez de faire ; l'idée n'est pas de faire un test qui échoue. Ce que vous essayez de faire, c'est d'imaginer la prochaine étape que vous voulez faire, c'est de faire évoluer l'implémentation de façon nécessaire et suffisante pour créer de la valeur. On le reformule souvent comme "écrire la spécification suivante". En gros, votre prochain test est votre prochaine spécification sur la façon dont le logiciel devrait se comporter... et parce que vous ne l'avez pas encore fait, le logiciel va échouer... mais vous n'êtes pas là pour écrire un test qui échoue.<br/> | Voici une autre façon de le représenter et d'y réfléchir. Bien que "écrire un test qui échoue" soit correct en tant que procédure, cela reste assez déroutant parce que ce n'est pas ce que vous essayez de faire ; l'idée n'est pas de faire un test qui échoue. Ce que vous essayez de faire, c'est d'imaginer la prochaine étape que vous voulez faire, c'est de faire évoluer l'implémentation de façon nécessaire et suffisante pour créer de la valeur. On le reformule souvent comme "écrire la spécification suivante". En gros, votre prochain test est votre prochaine spécification sur la façon dont le logiciel devrait se comporter... et parce que vous ne l'avez pas encore fait, le logiciel va échouer... mais vous n'êtes pas là pour écrire un test qui échoue.<br/> | ||
| Ligne 57 : | Ligne 59 : | ||
La manière classique, en utilisant Cucumber et SpecFlow et tout autre outil qui utilise une syntaxe semi-structurée appelée Gherkin, c'est de documenter et de définir ces spécifications. Vous finirez par avoir ce qu'on appelle des fichiers feature.<br/> | La manière classique, en utilisant Cucumber et SpecFlow et tout autre outil qui utilise une syntaxe semi-structurée appelée Gherkin, c'est de documenter et de définir ces spécifications. Vous finirez par avoir ce qu'on appelle des fichiers feature.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Feature-file.png|border|800px]]<br/> | [[Fichier:Feature-file.png|border|800px|link=]]<br/> | ||
<br/> | <br/> | ||
Les fichiers feature sont simplement des fichiers texte. Ils ont une semi-structure, il y a une syntaxe, et les mots-clés sont en bleu. L'intention est que n'importe qui de votre domaine devrait être capable de lire vos fichiers feature et de comprendre exactement quelle est l'intention du système.<br/> | Les fichiers feature sont simplement des fichiers texte. Ils ont une semi-structure, il y a une syntaxe, et les mots-clés sont en bleu. L'intention est que n'importe qui de votre domaine devrait être capable de lire vos fichiers feature et de comprendre exactement quelle est l'intention du système.<br/> | ||
| Ligne 89 : | Ligne 91 : | ||
Mais la question pertinente au moment de décider de la mise en oeuvre d'un test est la suivante : ''Qui'' est intéressé par la lecture de ces tests ?<br/> | Mais la question pertinente au moment de décider de la mise en oeuvre d'un test est la suivante : ''Qui'' est intéressé par la lecture de ces tests ?<br/> | ||
<br/> | <br/> | ||
Si vous voulez obtenir des feedbacks de votre métier/entreprise au sujet de quelque chose, si c'est un comportement qui est vraiment important pour votre produit et que votre métier/entreprise va dire "non, ça ne devrait pas fonctionner comme ça", "oui, ça devrait fonctionner comme ça", pensez vraiment à écrire ces tests d'une façon qui leur permette de lire ces tests et de dire "c'est ce que nous voulons". Cucumber, SpecFlow, les outils qui utilisent Gherkin vous permettent de le faire directement dans un langage universel. Cependant, vous n'avez toujours pas besoin de les utiliser, vous pouvez écrire de longues phrases au sein du cadre technique sur lequel vous travaillez et qui pourrait générer cette documentation lisible que vous pouvez partager avec votre entreprise. Vous pouvez le faire dans JUnit, vous pouvez le faire dans CPP Lite, vous pouvez le faire dans n'importe lequel de ces outils ; ce n'est pas un problème.<br/> | Si vous voulez obtenir des feedbacks de votre métier/entreprise au sujet de quelque chose, si c'est un comportement qui est vraiment important pour votre produit et que votre métier/entreprise va dire "non, ça ne devrait pas fonctionner comme ça", "oui, ça devrait fonctionner comme ça", pensez vraiment à écrire ces tests d'une façon qui leur permette de lire ces tests et de dire "c'est ce que nous voulons". Cucumber, SpecFlow, les outils qui utilisent Gherkin vous permettent de le faire directement dans un langage universel. Cependant, vous n'avez toujours pas besoin de les utiliser, vous pouvez écrire de longues phrases au sein du cadre technique sur lequel vous travaillez et qui pourrait générer cette documentation lisible que vous pouvez partager avec votre métier/entreprise. Vous pouvez le faire dans JUnit, vous pouvez le faire dans CPP Lite, vous pouvez le faire dans n'importe lequel de ces outils ; ce n'est pas un problème.<br/> | ||
<br/> | <br/> | ||
Ce que vous devez faire, c'est vous assurer que cela s'exprime d'une manière qui vous permette d'obtenir les feedbacks des personnes intéressées, les gens qui ont un enjeu.<br/> | Ce que vous devez faire, c'est vous assurer que cela s'exprime d'une manière qui vous permette d'obtenir les feedbacks des personnes intéressées, les gens qui ont un enjeu.<br/> | ||
| Ligne 100 : | Ligne 102 : | ||
|alignment=left | |alignment=left | ||
}} | }} | ||
<br/> | |||
