« Less - Développement piloté par les tests » : différence entre les versions

De Wiki Agile
← Modification précédenteModification suivante →
VisuelWikicode
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.
Récupérée de "https://wikiagile.coach/Less_-_Développement_piloté_par_les_tests"