« Less - Développement piloté par les tests » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (2 versions intermédiaires par le même utilisateur non affichées) | |||
| 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]] | ||
| Ligne 21 : | 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/> | ||
| Ligne 60 : | Ligne 61 : | ||
= 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/> | |||
<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/> | |||
<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 | |||
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, | |||
De cette manière, le TDD encourage un couplage plus lâche, plus simple, une configuration plus simple | |||