« Introduction à TDD et BDD » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 21 : | Ligne 21 : | ||
<br/> | <br/> | ||
==Qu'est-ce que TDD ?== | ==Qu'est-ce que TDD ?== | ||
[[Fichier:Write-failing-test.png|border| | [[Fichier:Write-failing-test.png|border|800px]]<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 "écrire un test qui échoue" et ensuite faire passer le test avec succès et ensuite refactorer ; vous continuez à tourner dans cette boucle. C'est le cycle du TDD, c'est très simple. Il y a trois petits titres ; il y a des flèches colorées entre elles. 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 "écrire un test qui échoue" et ensuite faire passer le test avec succès et ensuite refactorer ; vous continuez à tourner dans cette boucle. C'est le cycle du TDD, c'est très simple. Il y a trois petits titres ; il y a des flèches colorées entre elles. 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| | [[Fichier:Tdd-bullet-points.png|border|800px]]<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/> | ||
