« Introduction à TDD et BDD » : différence entre les versions
De Wiki Agile
| Ligne 29 : | Ligne 29 : | ||
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/> | ||
<br/> | <br/> | ||
La seconde étape est de faire rapidement passer le test avec succès. L'intention n'est pas de tout concevoir parfaitement ; c'est de faire passer le test avec succès. L'ensemble de vos tests passe de l'échec à la réussite totale, et maintenant que tous vos tests sont réussis, il est possible de refactorer le code en toute sécurité. L'intention ici n'est pas d'obtenir la meilleure conception ; c'est de les passer au vert rapidement, et maintenant qu'ils sont tous au vert, vous pouvez les regarder et vous demander "comment puis-je améliorer cette conception", et vous pouvez améliorer la conception en toute sécurité grâce au refactoring.<br/> | La seconde étape est de faire rapidement passer le test avec succès. L'intention n'est pas de tout concevoir parfaitement ; c'est de faire passer le test avec succès. L'ensemble de vos tests passe de l'échec à la réussite totale, et maintenant que tous vos tests sont réussis, il est possible de refactorer le code en toute sécurité. L'intention ici n'est pas d'obtenir la meilleure conception ; c'est de les passer au vert rapidement, et maintenant qu'ils sont tous au vert, vous pouvez les regarder et vous demander "comment puis-je améliorer cette conception ?", et vous pouvez améliorer la conception en toute sécurité grâce au refactoring.<br/> | ||
<br/> | <br/> | ||
La troisième chose, c'est le refactoring. La boucle de refactoring dans le livre de Nat et Steve est en fait un cycle. Vous pouvez le dessiner de bien d'autres façons, mais l'idée est que vous ne vous contentez pas de vous lancer et refactorer pour dire que vous avez terminé ; vous vous lancez, vous regardez et voyez ce que vous aimeriez changer et vous le changer. Vous vous assurez que le test est encore vert, et vous regardez le code à nouveau et vous vous demandez "Y a-t-il un autre changement que je veux faire ?" ou "est-ce que ce refactoring a introduit une autre chose que je souhaite faire ?". Il s'agit d'un multi-processus en soi ; il ne s'agit pas d'une seule étape.<br/> | La troisième chose, c'est le refactoring. La boucle de refactoring dans le livre de Nat et Steve est en fait un cycle. Vous pouvez le dessiner de bien d'autres façons, mais l'idée est que vous ne vous contentez pas de vous lancer et refactorer pour dire que vous avez terminé ; vous vous lancez, vous regardez et voyez ce que vous aimeriez changer et vous le changer. Vous vous assurez que le test est encore vert, et vous regardez le code à nouveau et vous vous demandez "Y a-t-il un autre changement que je veux faire ?" ou "est-ce que ce refactoring a introduit une autre chose que je souhaite faire ?". Il s'agit d'un multi-processus en soi ; il ne s'agit pas d'une seule étape.<br/> | ||
