« Introduction à TDD et BDD » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| Ligne 66 : | Ligne 66 : | ||
<br/> | <br/> | ||
Les gens continuent encore en demandant : "J'ai aussi entendu parler du Test-Driven Development (ATDD : ''Développement piloté par les tests d'acceptation''). Qu'est-ce que c'est ? Quand dois-je l'utiliser ? Est-ce que c'est différent ?". La réalité est que vous pouvez trouver des sites Web qui vous diront quand utiliser quoi et dans quel environnement. On a posé la question suivante à [https://twitter.com/lunivore Liz Keogh], qui travaille avec [https://dannorth.net/introducing-bdd/ Dan North qui a inventé le terme BDD] : "quelle est la différence entre toutes ces choses ?"<br/> | Les gens continuent encore en demandant : "J'ai aussi entendu parler du Test-Driven Development (ATDD : ''Développement piloté par les tests d'acceptation''). Qu'est-ce que c'est ? Quand dois-je l'utiliser ? Est-ce que c'est différent ?". La réalité est que vous pouvez trouver des sites Web qui vous diront quand utiliser quoi et dans quel environnement. On a posé la question suivante à [https://twitter.com/lunivore Liz Keogh], qui travaille avec [https://dannorth.net/introducing-bdd/ Dan North qui a inventé le terme BDD] : "quelle est la différence entre toutes ces choses ?"<br/> | ||
''[https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/ Sa réponse] est : ce sont des noms | ''[https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/ Sa réponse] est : ce sont des noms différents pour les mêmes choses.'' | ||
<br/> | <br/> | ||
Il n'y a pas de différence fondamentale entre eux. Ce qui les unit, c'est qu'ils ont tous besoin qu'un groupe de personnes précise comment le logiciel doit se comporter, en collaborant avant sa mise en oeuvre. C'est ce qui est important, alors c'est peut-être à cela que nous devrions réduire la définition du BDD. L'idée est de travailler à partir d'une vue extérieure, en réfléchissant à la façon dont nous voulons avancer, nous utilisons des exemples pour nous assurer que tous les membres de l'équipe comprennent ce sur quoi nous venons de nous entendre, des exemples concrets avec des données concrètes, et nous écrivons ces exemples dans un langage universel : un langage utilisant des termes dérivés du domaine métier qui sont compris, sans ambiguïté, par tout le monde dans l'équipe.<br/> | Il n'y a pas de différence fondamentale entre eux. Ce qui les unit, c'est qu'ils ont tous besoin qu'un groupe de personnes précise comment le logiciel doit se comporter, en collaborant avant sa mise en oeuvre. C'est ce qui est important, alors c'est peut-être à cela que nous devrions réduire la définition du BDD. L'idée est de travailler à partir d'une vue extérieure, en réfléchissant à la façon dont nous voulons avancer, nous utilisons des exemples pour nous assurer que tous les membres de l'équipe comprennent ce sur quoi nous venons de nous entendre, des exemples concrets avec des données concrètes, et nous écrivons ces exemples dans un langage universel : un langage utilisant des termes dérivés du domaine métier qui sont compris, sans ambiguïté, par tout le monde dans l'équipe.<br/> | ||
<br/> | <br/> | ||
==Concevez vos tests - xDD== | |||
La sujet "xDD". De quoi s'agit-il ? La raison pour laquelle on appelle cela "Test-Driven" ou "Behaviour-Driven" ou "Acceptance Test-Driven" est que vous devez spécifier le comportement ''avant'' de mener l'implémentation. Il n'y a pas de "nous faisons une sorte de Behaviour-Driven", " nous faisons une sorte de Test-Driven", "nous écrivons les tests dans le sprint". Vous devez d'abord les écrire. C'est de cette façon que les tests pilotent, c'est comme cela que ça devient un processus de conception. C'est la spécification qui échoue, c'est le fait de la voir échouer, qui vous pousse à mener l'implémentation. C'est ce qui pousse le développeur ; c'est ce qu'il utilise pour écrire le code.<br/> | |||
<br/> | |||
Le second D est assez souvent utilisé pour "design" (conception). Je sais que ce n'est pas pour le "design", c'est pour le "développement", mais en fait nous concevons du code. Lorsque nous codons l'automatisation, nous devons penser à la façon dont elle va être utilisée, comment nous allons appeler cette méthode, comment nous allons déclencher ce comportement. En écrivant votre code en réponse à vos tests et en réfléchissant, vous assurez la testabilité, vous obtenez un code qui est testable, un code que vous comprenez. Vous bénéficiez d'un grand nombre d'avantages bien au-delà de la couverture de test.<br/> | |||
<br/> | |||
''Il ne s'agit pas de couverture de tests.''<br/> | |||
Finalement, vous obtenez un refactoring grâce au BDD et au TDD, et vous le faites jusqu'à ce que vous vous sentiez bien. Les gens se disent : "Eh bien, ce serait bien si nous savions quand nous devons refactorer". Faire un logiciel, ce n'est pas "mettre les spécifications en haut, tourner une manivelle et attendre que la bonne solution sorte".<br/> | |||
<br/> | |||
C'est une activité créative et même si je suis sûr que vous détestez qu'on vous prenne pour un créatif, vous êtes un créatif. Vous devez en avoir l'intuition.<br/> | |||
<br/> | |||
==Conclusions== | |||
