Introduction à TDD et BDD - Historique des versions

Fabrice Aimetti le 7 septembre 2023 à 13:53

2023-09-07T13:53:16Z

← Version précédente		Version du 7 septembre 2023 à 13:53
Ligne 13 :		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 23 :		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 59 :		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/>

Fabrice Aimetti le 4 avril 2019 à 08:02

2019-04-04T08:02:32Z

← Version précédente		Version du 4 avril 2019 à 08:02
Ligne 102 :		Ligne 102 :
	\|alignment=left		\|alignment=left
	}}		}}
			<br/>

Fabrice Aimetti le 27 février 2019 à 08:16

2019-02-27T08:16:57Z

← Version précédente		Version du 27 février 2019 à 08:16
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/>

Fabrice Aimetti : /* Conclusion */

2019-02-26T17:44:07Z

Conclusion

← Version précédente		Version du 26 février 2019 à 17:44
Ligne 89 :		Ligne 89 :
	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/>

Fabrice Aimetti : /* TDD et BDD : différences et oppositions */

2019-02-26T17:35:11Z

TDD et BDD : différences et oppositions

← Version précédente		Version du 26 février 2019 à 17:35
Ligne 69 :		Ligne 69 :
	''[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.''		''[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 son implémentation. 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==		==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/>		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/>

Fabrice Aimetti : /* Qu'est-ce que le BDD ? */

2019-02-26T17:32:06Z

Qu'est-ce que le BDD ?

← Version précédente		Version du 26 février 2019 à 17:32
Ligne 49 :		Ligne 49 :
	Le deuxième niveau, une fois que nous avons obtenu cette collaboration, c'est de la '''documenter''' d'une façon qui soit significative pour tous ceux qui l'examinent, qui pourraient y jeter un coup d'oeil plus tard et qui voudraient peut-être y apporter des commentaires. Généralement, cela se fait en utilisant un langage universel. Les gens utilisent souvent les mots "Given" (''étant donné''), "When" (''lorsque''), "Then" (''alors''), mais ce n'est pas nécessaire. L'idée est que nous avons collaboré et qu'il s'agit d'une compréhension partagée. Cela nous a permis de nous assurer qu'il y a un objectif de collaboration que nous essayons d'atteindre, et une fois que nous avons réussi à collaborer, cela vaut la peine d'essayer de le documenter de telle façon que personne n'ait besoin d'être dans la salle au même moment, pour que l'apprentissage partagé puisse être diffusé. Enfin, si cela convient à nos équipes et à nos projets, nous '''automatisons''' nos tests pour piloter le comportement.<br/>		Le deuxième niveau, une fois que nous avons obtenu cette collaboration, c'est de la '''documenter''' d'une façon qui soit significative pour tous ceux qui l'examinent, qui pourraient y jeter un coup d'oeil plus tard et qui voudraient peut-être y apporter des commentaires. Généralement, cela se fait en utilisant un langage universel. Les gens utilisent souvent les mots "Given" (''étant donné''), "When" (''lorsque''), "Then" (''alors''), mais ce n'est pas nécessaire. L'idée est que nous avons collaboré et qu'il s'agit d'une compréhension partagée. Cela nous a permis de nous assurer qu'il y a un objectif de collaboration que nous essayons d'atteindre, et une fois que nous avons réussi à collaborer, cela vaut la peine d'essayer de le documenter de telle façon que personne n'ait besoin d'être dans la salle au même moment, pour que l'apprentissage partagé puisse être diffusé. Enfin, si cela convient à nos équipes et à nos projets, nous '''automatisons''' nos tests pour piloter le comportement.<br/>
	<br/>		<br/>
	''Nous collaborons, nous documentons cette collaboration sous une forme de spécification, puis nous automatisons cette spécification pour ~~faire~~ piloter l'implémentation.''		''Nous collaborons, nous documentons cette collaboration sous une forme de spécification, puis nous automatisons cette spécification pour piloter l'implémentation.''
	<br/>		<br/>

Fabrice Aimetti le 26 février 2019 à 17:31

2019-02-26T17:31:42Z

← Version précédente		Version du 26 février 2019 à 17:31
Ligne 47 :		Ligne 47 :
	Le premier niveau est d'amener les développeurs, les testeurs et les gens du métier à se parler entre eux. C'est l'origine du BDD. Tous ceux qui pensent "nous faisons du BDD parce que nous utilisons "Given", "When", "Then" n'ont (souvent) pas compris. "Given", "When", "Then" n'a rien à voir avec BDD. BDD signifie Behaviour-Driven Development (''développement piloté par le comportement'') et l'intention réelle est d'essayer de déterminer ce que votre client ou votre métier/entreprise attend du logiciel avant de commencer à travailler sur celui-ci. La première façon d'y parvenir est de réellement '''collaborer''' avec ces personnes.<br/>		Le premier niveau est d'amener les développeurs, les testeurs et les gens du métier à se parler entre eux. C'est l'origine du BDD. Tous ceux qui pensent "nous faisons du BDD parce que nous utilisons "Given", "When", "Then" n'ont (souvent) pas compris. "Given", "When", "Then" n'a rien à voir avec BDD. BDD signifie Behaviour-Driven Development (''développement piloté par le comportement'') et l'intention réelle est d'essayer de déterminer ce que votre client ou votre métier/entreprise attend du logiciel avant de commencer à travailler sur celui-ci. La première façon d'y parvenir est de réellement '''collaborer''' avec ces personnes.<br/>
	<br/>		<br/>
	Le deuxième niveau, une fois que nous avons obtenu cette collaboration, c'est de la '''documenter''' d'une façon qui soit significative pour tous ceux qui l'examinent, qui pourraient y jeter un coup d'oeil plus tard et qui voudraient peut-être y apporter des commentaires. Généralement, cela se fait en utilisant un langage universel. Les gens utilisent souvent les mots "Given" (''étant donné''), "When" (''lorsque''), "Then" (''alors''), mais ce n'est pas nécessaire. L'idée est que nous avons collaboré et qu'il s'agit d'une compréhension partagée. Cela nous a permis de nous assurer qu'il y a un objectif de collaboration que nous essayons d'atteindre, et une fois que nous avons réussi à collaborer, cela vaut la peine d'essayer de le documenter de telle façon que personne n'ait besoin d'être dans la salle au même moment, pour que l'apprentissage partagé puisse être diffusé. Enfin, si cela convient à nos équipes et à nos projets, nous ''automatisons'' nos tests pour piloter le comportement.<br/>		Le deuxième niveau, une fois que nous avons obtenu cette collaboration, c'est de la '''documenter''' d'une façon qui soit significative pour tous ceux qui l'examinent, qui pourraient y jeter un coup d'oeil plus tard et qui voudraient peut-être y apporter des commentaires. Généralement, cela se fait en utilisant un langage universel. Les gens utilisent souvent les mots "Given" (''étant donné''), "When" (''lorsque''), "Then" (''alors''), mais ce n'est pas nécessaire. L'idée est que nous avons collaboré et qu'il s'agit d'une compréhension partagée. Cela nous a permis de nous assurer qu'il y a un objectif de collaboration que nous essayons d'atteindre, et une fois que nous avons réussi à collaborer, cela vaut la peine d'essayer de le documenter de telle façon que personne n'ait besoin d'être dans la salle au même moment, pour que l'apprentissage partagé puisse être diffusé. Enfin, si cela convient à nos équipes et à nos projets, nous '''automatisons''' nos tests pour piloter le comportement.<br/>
	<br/>		<br/>
	''Nous collaborons, nous documentons cette collaboration sous une forme de spécification, puis nous automatisons cette spécification pour faire piloter l'implémentation.''		''Nous collaborons, nous documentons cette collaboration sous une forme de spécification, puis nous automatisons cette spécification pour faire piloter l'implémentation.''

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

2019-02-26T17:28:06Z

Qu'est-ce que TDD ?

← Version précédente		Version du 26 février 2019 à 17:28
Ligne 23 :		Ligne 23 :
	[[Fichier:Write-failing-test.png\|border\|800px]]<br/>		[[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 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 ~~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 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]]<br/>

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

2019-02-26T17:22:20Z

Qu'est-ce que TDD ?

← Version précédente		Version du 26 février 2019 à 17:22
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/>

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

2019-02-26T17:12:07Z

Qu'est-ce que TDD ?

← Version précédente		Version du 26 février 2019 à 17:12
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 ~~les~~ refactorer 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/>

Introduction à TDD et BDD - Historique des versions

Fabrice Aimetti le 7 septembre 2023 à 13:53

Fabrice Aimetti le 4 avril 2019 à 08:02

Fabrice Aimetti le 27 février 2019 à 08:16

Fabrice Aimetti : /* Conclusion */

Fabrice Aimetti : /* TDD et BDD : différences et oppositions */

Fabrice Aimetti : /* Qu'est-ce que le BDD ? */

Fabrice Aimetti le 26 février 2019 à 17:31

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

Fabrice Aimetti : /* Conclusion */

Fabrice Aimetti : /* TDD et BDD : différences et oppositions */

Fabrice Aimetti : /* Qu'est-ce que le BDD ? */

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

Fabrice Aimetti : /* Qu'est-ce que TDD ? */

Fabrice Aimetti : /* Qu'est-ce que TDD ? */