Less - Développement piloté par les tests - Historique des versions

Fabrice Aimetti le 8 mars 2021 à 05:50

Fabrice Aimetti — Mon, 08 Mar 2021 05:50:23 GMT

← Version précédente		Version du 8 mars 2021 à 05:50
Ligne 22 :		Ligne 22 :
	# Refactorer le code afin qu’il soit propre		# Refactorer le code afin qu’il soit propre

	[[Fichier:Tdd-cycle-fr.png\|centré\|254px\|TDD\|border]]		[[Fichier:Tdd-cycle-fr.png\|centré\|254px\|TDD\|border\|link=]]

	Dans un langage comme Java, ce cycle ne prend pas plus de 5 minutes. Dans des langages plus anciens, ayant des temps de compilation plus longs et moins d’outils de refactoring automatisés, ce cycle est plus long - 20 minutes probablement.<br/>		Dans un langage comme Java, ce cycle ne prend pas plus de 5 minutes. Dans des langages plus anciens, ayant des temps de compilation plus longs et moins d’outils de refactoring automatisés, ce cycle est plus long - 20 minutes probablement.<br/>

Fabrice Aimetti le 13 mai 2020 à 15:46

Fabrice Aimetti — Wed, 13 May 2020 15:46:18 GMT

← Version précédente		Version du 13 mai 2020 à 15:46
Ligne 1 :		Ligne 1 :
			[[Category: Nicolas Mereaux]]
	[[Category: Portail LeSS]]		[[Category: Portail LeSS]]
	[[Category: Portail Equipe de développement]]		[[Category: Portail Equipe de développement]]

Fabrice Aimetti : /* Développement piloté par les tests pour une meilleure architecture */

Fabrice Aimetti — Sun, 08 Mar 2020 21:13:09 GMT

Développement piloté par les tests pour une meilleure architecture

← Version précédente		Version du 8 mars 2020 à 21:13
Ligne 60 :		Ligne 60 :

	= Développement piloté par les tests pour une meilleure architecture =		= Développement piloté par les tests pour une meilleure architecture =
			Le TDD peut aider à améliorer l’architecture d’un système. Comment ?<br/>
	~~TDD can help improve the architecture of a system. How?~~		<br/>
			Quand nous faisons de l’accompagnement, une demande d’assistante fréquente qui nous est adressée est d’aider à assouplir "l’architecture rigide" de notre client. Cela se réduit le plus souvent à des problèmes de couplages très étroits entre les composants, un problème assez répandu dans du code patrimonial/historique écrit sans TDD parce que le développeur d’origine n’avait pas essayé de tester le composant de manière isolé.<br/>
	Le TDD peut aider à améliorer l’architecture d’un système. Comment ?		<br/>
			D’un autre côté, lorsqu’un développeur créé un nouveau composant (comme une classe) avec le TDD, ou refactore un composant patrimonial/historique pour être testable unitairement, il doit casser les dépendances de ce composant afin qu’il soit testable de manière isolé. Cela exige de faire une conception (ou un refacoring) orientée injection de dépendances et d’augmenter l’utilisation de mécanismes pour plus de flexibilité : interfaces, polymorphisme, schéma de conceptions, frameworks d’injection de dépendances, pointeurs de fonctions, etc.<br/>
	When we are coaching, a frequent request is help for dealing with our client’s “inflexible architecture.” This most often boils down to problems in high coupling between components—a common problem in legacy code written without TDD because the original developer did not try to test the component in isolation.		<br/>
			De cette manière, le TDD encourage un couplage plus lâche, plus simple, une configuration plus simple, en somme, les qualités d’une bonne architecture.<br/>
	Quand nous faisons de l’accompagnement, une demande d’assistante fréquente qui nous est adressée est d’aider à assouplir « l’architecture ~~inflexible»~~ de notre client. Cela se réduit le plus souvent à des problèmes de couplages très étroits entre les composants - un problème assez répandu dans du code ~~ancien~~ écrit sans TDD parce que le développeur d’origine n’avait pas essayé de tester le composant de manière isolé.

	On the other hand, when a developer creates a new component (such as a class) with TDD, or refactors a legacy component to be unit-testable, they must break the dependencies of that component so that it is testable in isolation. That requires designing (or refactoring) for dependency injection and increased use of mechanisms for flexibility: interfaces, polymorphism, design patterns, dependency injection frameworks, function pointers, and more.

	D’un autre côté, lorsqu’un développeur créé un nouveau composant (comme une classe) avec le TDD, ou refactore un composant historique pour être testable unitairement, il doit casser les dépendances de ce composant afin qu’il soit testable de manière isolé. Cela exige de faire une conception orientée injection de dépendances et d’augmenter l’utilisation de mécanismes pour plus de flexibilité : interfaces, polymorphisme, schéma de conceptions, ~~''framework''~~ d’injection de dépendances, pointeurs de fonctions, etc

	~~In this way, TDD encourages lower coupling and simple, flexible configuration—qualities of a good architecture~~.

	De cette manière, le TDD encourage un couplage plus lâche, plus simple, une configuration plus simple - en somme, les qualités d’une bonne architecture.

Fabrice Aimetti : /* Coachs internes et externes */

Fabrice Aimetti — Sun, 08 Mar 2020 21:07:26 GMT

Coachs internes et externes

← Version précédente		Version du 8 mars 2020 à 21:07
Ligne 49 :		Ligne 49 :
	== Coachs internes et externes ==		== Coachs internes et externes ==

	External coaches are needed when adopting TDD because the com- petence does not yet exist inside the company. But, over time, growing internal coaches reduces the dependence on externals and the cost of coaching.		Des coachs externes sont nécessaires lors de l’adoption de TDD car la compétence n’existe pas encore dans l’entreprise. Mais, avec le temps, la montée en compétence de coachs internes diminuent la dépendance vis-à-vis de coachs externes et en réduit le coût.<br/>
			<br/>
	Des coachs externes sont nécessaires ~~quant à~~ l’adoption de TDD car la compétence n’existe pas encore dans l’entreprise. Mais, avec le temps, la montée en compétence de coachs internes diminuent la dépendance vis-à-vis de coachs externes et en réduit le coût.

	~~That said, we have seen several attempts fail to develop internal coaches. Some reasons:~~

	Ceci dit, nous avons assisté à plusieurs échecs quant à la mise en place de coachs internes. Voici quelques raisons de ces échecs :		Ceci dit, nous avons assisté à plusieurs échecs quant à la mise en place de coachs internes. Voici quelques raisons de ces échecs :

	* No structure was in place to decide when and with which teams to work.
	* No time was reserved for coaching. Instead the internal coaches were asked to do normal development.
	* Developers were less eager to learn from internal coaches…you are never a prophet in your own land.
	* Coaching skills were not appreciated and further developed. The result is that skilled internal coaches often leave to be an external coach.

	* Aucune structure n’était en place pour décider avec quelle équipe travailler et quand le faire.		* Aucune structure n’était en place pour décider avec quelle équipe travailler et quand le faire.
	* Aucun temps n’était accordé pour du coaching. Au lieu de cela il était demandé aux coachs internes de faire du développement « traditionnel ».		* Aucun temps n’était accordé pour du coaching. Au lieu de cela il était demandé aux coachs internes de faire du développement "traditionnel".
	* Les développeurs étaient moins enthousiastes d’apprendre de coachs internes … vous n’êtes jamais prophète dans votre propre pays.		* Les développeurs étaient moins enthousiastes d’apprendre de coachs internes... vous n’êtes jamais prophète dans votre propre pays.
	* Les compétences de coach n’étaient ni appréciées ni encouragées à être davantage développées. En conséquence de quoi, les coachs internes compétents partaient souvent pour devenir coach externe.		* Les compétences de coach n’étaient ni appréciées ni encouragées à être davantage développées. En conséquence de quoi, les coachs internes compétents partaient souvent pour devenir coach externe.
			<br/>
	~~Choose both internal and external coaching. Depending on either of them alone is risky but combining them can lead to good results.~~		Choisissez les deux, du coaching interne et du coaching externe. Dépendre de l’un des deux uniquement est risqué mais les combiner peut conduire à de bons résultats.<br/>

	Choisissez les deux, du coaching interne et du coaching externe. Dépendre de l’un des deux uniquement est risqué mais les combiner peut conduire à de bons résultats.

	= Développement piloté par les tests pour une meilleure architecture =		= Développement piloté par les tests pour une meilleure architecture =

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti — Sun, 08 Mar 2020 21:04:38 GMT

Recourir à des coachs en TDD

← Version précédente		Version du 8 mars 2020 à 21:04
Ligne 46 :		Ligne 46 :
	<br/>		<br/>
	Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !<br/>		Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !<br/>
	~~<br/>~~

	== Coachs internes et externes ==		== Coachs internes et externes ==

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti — Sun, 08 Mar 2020 21:04:25 GMT

Recourir à des coachs en TDD

← Version précédente		Version du 8 mars 2020 à 21:04
Ligne 42 :		Ligne 42 :

	À la relecture du projet de livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. "L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching" a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions aussi bien pu mettre une pancarte "Essayez... Engagez-nous...". Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.<br/>		À la relecture du projet de livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. "L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching" a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions aussi bien pu mettre une pancarte "Essayez... Engagez-nous...". Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.<br/>
			<br/>
	Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binôme pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code, y compris le code des tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.<br/>		Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binôme pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code, y compris le code des tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.<br/>
			<br/>
	Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !<br/>		Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !<br/>
			<br/>

	== Coachs internes et externes ==		== Coachs internes et externes ==

Fabrice Aimetti : /* Qu’est-ce que le Développement piloté par les tests ? */

Fabrice Aimetti — Sun, 08 Mar 2020 21:04:06 GMT

Qu’est-ce que le Développement piloté par les tests ?

← Version précédente		Version du 8 mars 2020 à 21:04
Ligne 23 :		Ligne 23 :
	[[Fichier:Tdd-cycle-fr.png\|centré\|254px\|TDD\|border]]		[[Fichier:Tdd-cycle-fr.png\|centré\|254px\|TDD\|border]]

	Dans un langage comme Java, ce cycle ne prend pas plus de 5 minutes. Dans des langages plus anciens, ayant des temps de compilation plus longs et moins d’outils de refactoring automatisés, ce cycle est plus long - 20 minutes probablement.		Dans un langage comme Java, ce cycle ne prend pas plus de 5 minutes. Dans des langages plus anciens, ayant des temps de compilation plus longs et moins d’outils de refactoring automatisés, ce cycle est plus long - 20 minutes probablement.<br/>
			<br/>
	Est-ce que le développement piloté par les tests est différent dans le cadre du développement de produits de taille importante ? Non, car il s’agit d’une pratique individuelle de développeur, peu importe le nombre de personnes impliquées dans le développement. La quantité de code patrimonial/historique, les anciennes technologies et les développements dans l’embarqué ont un impact sur les tests unitaires et sur le développement piloté par les tests. En conséquence, la plupart des expérimentations de cet article sont en lien avec ces sujets.		Est-ce que le développement piloté par les tests est différent dans le cadre du développement de produits de taille importante ? Non, car il s’agit d’une pratique individuelle de développeur, peu importe le nombre de personnes impliquées dans le développement. La quantité de code patrimonial/historique, les anciennes technologies et les développements dans l’embarqué ont un impact sur les tests unitaires et sur le développement piloté par les tests. En conséquence, la plupart des expérimentations de cet article sont en lien avec ces sujets.<br/>

	== Un cycle TDD type devrait être … ==		== Un cycle TDD type devrait être … ==

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti — Sun, 08 Mar 2020 21:03:42 GMT

Recourir à des coachs en TDD

← Version précédente		Version du 8 mars 2020 à 21:03
Ligne 41 :		Ligne 41 :
	== Recourir à des coachs en TDD ==		== Recourir à des coachs en TDD ==

	À la relecture du projet de livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. "L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching" a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions aussi bien pu mettre une pancarte "Essayez... Engagez-nous...". Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.		À la relecture du projet de livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. "L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching" a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions aussi bien pu mettre une pancarte "Essayez... Engagez-nous...". Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.<br/>

	Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binôme pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code, y compris le code des tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.		Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binôme pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code, y compris le code des tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.<br/>

	Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !		Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !<br/>

	== Coachs internes et externes ==		== Coachs internes et externes ==

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti — Sun, 08 Mar 2020 21:03:12 GMT

Recourir à des coachs en TDD

← Version précédente		Version du 8 mars 2020 à 21:03
Ligne 41 :		Ligne 41 :
	== Recourir à des coachs en TDD ==		== Recourir à des coachs en TDD ==

	~~When a client of ours reviewed~~ a ~~draft of the companion book, he mentioned that we ought to stress~~ coaching ~~more~~. ~~“One of our mistakes is that we didn’t provide enough~~ coaching~~,” he said~~. ~~Though we agreed with him~~, ~~we pointed out that since we are both~~ consultants ~~and provide such coaching~~, ~~this advice would not be very credible~~. ~~We might as well add an experiment “Try…Hire us~~.~~” Thus~~, ~~we minimized the advice related to hiring coaches~~.		À la relecture du projet de livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. "L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching" a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions aussi bien pu mettre une pancarte "Essayez... Engagez-nous...". Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.

	À la relecture du brouillon du livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. « L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching » a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions bien pu aussi bien mettre une pancarte « Essayez … Engagez-nous ». Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.		Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binôme pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code, y compris le code des tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.

	But related to test-driven development, we cannot stress strongly enough: Hire coaches! Adopting TDD means unlearning traditional programming and relearning how to design and code. We rarely meet people who were able to adopt this by self-education. Most developers need a coach to pair-program with them for days or weeks. The coach constantly reminds them to write the tests first and to really clean up the code—including the test code. He helps them apply TDD and refactoring to their real code.

	Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en ~~binome~~ pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code - y compris le code de tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.

	~~Test-driven development might be the hardest agile practice to adopt, but it is also one of the biggest opportunities for improving the quality of the design and code. Hire coaches!~~

	Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !		Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !

Fabrice Aimetti : /* Un cycle TDD type devrait être … */

Fabrice Aimetti — Sun, 08 Mar 2020 20:58:54 GMT

Un cycle TDD type devrait être …

← Version précédente		Version du 8 mars 2020 à 20:58
Ligne 29 :		Ligne 29 :
	== Un cycle TDD type devrait être … ==		== Un cycle TDD type devrait être … ==

	'''Short''' The turnaround time for passing each test is short. It could take 5 mins per cycle. '''Rhythmic''' You’ll feel the rhythm distinctly - “red, green, refactor… red, green refactor…” '''Incremental''' You’ll know that as you write and pass more tests, working functionalities are being build up incrementally. '''Design-focused''' With good knowledge of software design principles, you’ll discover TDD is not a testing technique but a method of designing software. '''Disciplined''' TDD is a different way of developing software. To break the old habit of “code and fix” and to adopt a new habit will require discipline and persistence.		* '''Court''' : le temps de traitement pour passer chaque test est court. Cela pourrait prendre 5 minutes par cycle.
			* '''Rhythmique''' vous sentirez le rythme très distinctement - "rouge, vert, refactorer... rouge, vert, refactorer..."
	* '''Court''' : Le temps de traitement pour passer chaque test est court. Cela ~~devrait~~ prendre 5 minutes par cycle.		* '''Incrémental''' : vous saurez au fur et à mesure que vous écrirez et ferez passer de plus en plus de tests, que des fonctionnalités sont construites de manière incrémentale.
	* '''Rhythmique''' ~~Vous~~ sentirez le rythme très distinctement - « rouge, vert, refactorer … rouge, vert, refactorer ~~… »~~		* '''Focalisé sur la conception''' : avec une bonne connaissance des principes de conception logicielle, vous découvrirez que le développement piloté par les tests n’est pas une technique de tests mais une méthode pour concevoir du logiciel.
	* '''Incrémental''' : ~~Vous~~ saurez au fur et à mesure que vous écrirez et ferez passer de plus en plus de tests, que des fonctionnalités sont construites de manière incrémentale		* '''Discipliné''' : le TDD est une autre façon de développer du logiciel. Casser les vieilles habitudes "coder et corriger" pour adopter une nouvelle habitude exigera de la discipline et de la persévérance
	* '''Focalisé sur la conception''' : ~~Avec~~ une bonne connaissance des principes de conception logicielle, vous découvrirez que le développement piloté par les tests n’est pas une technique de tests mais une méthode pour concevoir du logiciel.
	* '''Discipliné''' : Le TDD est une autre façon de développer du logiciel. Casser les vieilles habitudes « coder et corriger » pour adopter une nouvelle habitude exigera de la discipline et de la persévérance

	= Pourquoi le TDD ? =		= Pourquoi le TDD ? =

Less - Développement piloté par les tests - Historique des versions

Fabrice Aimetti le 8 mars 2021 à 05:50

Fabrice Aimetti le 13 mai 2020 à 15:46

Fabrice Aimetti : /* Développement piloté par les tests pour une meilleure architecture */

Fabrice Aimetti : /* Coachs internes et externes */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Qu’est-ce que le Développement piloté par les tests ? */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Un cycle TDD type devrait être … */

Fabrice Aimetti : /* Développement piloté par les tests pour une meilleure architecture */

Fabrice Aimetti : /* Coachs internes et externes */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Qu’est-ce que le Développement piloté par les tests ? */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Recourir à des coachs en TDD */

Fabrice Aimetti : /* Un cycle TDD type devrait être … */