Le document présente les concepts de test-driven development (TDD) et de refactoring, en explorant l'approche de l'Extreme Programming (XP) qui favorise le développement itératif, la communication directe, et l'importance des tests. Il souligne que le TDD implique d'écrire des tests avant le code, tandis que le refactoring vise à améliorer la structure du code sans en changer le comportement. Les avantages des tests unitaires et les techniques comme l'injection de dépendance sont également abordés pour assurer la qualité et la maintenabilité du code.

1. TDD et Refactoring
Walid
Skouri

2. Plan
• Introduction
• L’eXtreme Programming
• Les bases du TDD
• Les tests unitaires
• Le refactoring

3. Introduction

4. Introduction
• Introduction
• L’eXtreme Programming
• Les bases du TDD
• Le refactoring

5. Introduction
• Les démarches traditionnelles
– spécification > conception > réalisation > validation
– Concentre la plupart des décision au début d’un projet
– Les client réalisent que leurs besoins ont changé

6. Introduction
Accepter ce changment
• C’est une composante incontournable de
tout projet
• Approche XP

7. eXtreme Programming

8. XP
L’idée
• Réduction significative de la durée du cycle
de développement:
– Réduction du temps entre :
• L’implémentation d’une fonctionnalité
• Mise en production d’une nouvelle version du logiciel

9. XP
Comment
• On ne fait de conception que pour les fonctionnalités
existantes, pas pour les fonctionnalités futures:
– On ne fait de généralisations dans la conception que lorsque
des besoins concrets se font sentir.
– On n'introduit pas d'optimisations si elles ne sont pas
demandées par le client.
• Priorité :
– Travail actuel bien fait : Code testé, simple, lisible et sans
duplication

10. XP
Principaux éléments de fonctionnement de XP
• Cycles itératifs pilotés par le client : Le projet progresse au rythme d'itérations
très courtes, dont le contenu fonctionnel est déterminé par le client.
• Travail d'équipe auto-organisé : L'équipe travaille réellement... en équipe. Les
développeurs organisent eux-mêmes leur travail, interviennent sur l'ensemble du
code, travaillent systématiquement en binômes, et synchronisent leurs
développements plusieurs fois par jour.
• Programmation pilotée par les tests : les développeurs écrivent des test
automatiques pour chaque portion de code qu'ils conçoivent, et ils s'appuient sur
ces tests pour affiner et améliorer sans cesse la conception de l'application sans
craindre de régression.

11. XP
Le coût des changements
Traditionnel
Coût des
changement
s
XP
Temps

12. XP
Les valeurs de XP
• Communication : XP favorise le contact humain, la communication directe, plutôt que le cloisonnement
des activités et les échanges de courriers électroniques ou de documents formels. Les développeurs
travaillent directement avec la maîtrise d'ouvrage, les testeurs sont intégrés à l'équipe de développement,
etc.
• Feedback : qu'il s'agisse d'itérations courtes, de livraisons fréquentes, de travail en binômes ou de tests
automatiques exécutés en permanence, la plupart des pratiques XP sont conçues pour donner un
maximum de feedback sur le déroulement du projet afin de corriger la trajectoire au plus tôt. En particulier,
les points de début d'itération offrent à l'équipe le moyen de prendre du recul sur son fonctionnement et de
l'améliorer sans cesse au fil des itérations.
• Simplicité : XP relève le défi suivant : « que pouvons-nous arrêter de faire tout en continuant à créer
efficacement un logiciel qui réponde aux besoins réels du client ? ». Cette recherche de simplification
touche le processus lui-même, mais aussi l'outil fabriqué (la mécanique de planification incite le client à
focaliser les efforts sur les fonctions prioritaires) ou encore la conception de l'application (guidée par un
principe de « You ain't gonna need it »).

13. Les bases du TDD

14. Les bases du TDD
Tests au début du développement
Ecriture des Ecriture du
tests code
Tests
Commencer Fini
échoués

15. Les bases du TDD
Développements pilotés par les tests
Code Tests
propre échoués
Refactoring
Tous les
tests
réussis

16. TDD

17. Les bases du TDD
Recommandations
• Ne jamais écrire de code sans avoir de
tests qui échouent
• Les tests doivent être représentatifs des
spécifications

18. Les test unitaires

19. Les tests unitaires
• Il permettent
– De contrôler et conserver la qualité du produit tout
au long du projet
– De se focaliser sur l’amélioration du code, plutôt
que sur les bugs
– D’améliorer la productivité de l’équipe en
automatisant un maximum de tâches redondantes
et ennuyantes

20. Les tests unitaires
Testabilité du code
• Privilégier la composition à l’héritage
• Isoler les dépendances
• Injecter les dépendances

21. Les tests unitaires
Testabilité du code
• Privilégier la composition à l’héritage
Héritage Composition
class Fruit { class Fruit {
//... } //... }
class Apple extends Fruit { class Apple {
//... } private Fruit fruit = new Fruit(); //... }
– L’héritage permet à la sous classe d’heriter toutes les fonctionnalité
– La composition permet une solution plus flexible et réutilisable
– Exemple: Permet d’instancier le l’objet composite avec différentes implémentations

22. Les tests unitaires
Testabilité du code
Injection de dépendance
• Se rapporte à la fourniture d'une dépendance
externe à un composant logiciel.
• Formes d’injection de dépendance
– interface injection
– setter injection
– constructor injection

23. Les tests unitaires
Testabilité du code
Injection du constructeur
public class ImportantClass { public class ImportantClass {
IFoo foo; IFoo foo;
public ImportantClass() public ImportantClass(IFoo foo) {
{ this.foo = foo;
this.foo = new }
EnterpriseFoo();
void doReallyImportantStuff() {
}
this.foo.bar();
void doReallyImportantStuff() {
this.foo.bar(); }
} }
}

24. Refactoring

25. Refactoring
C’est quoi?
• C’est une technique de restructuration du
code existant: modifier sa structure sans
changer son comportement externe
• Ensemble de petites modifications dans le
but d’améliorer le code

26. Refactoring
C’est quoi?
• Chaque transformation (ou Refactoring) ne
modifie qu’une petite partie du code mais un
ensemble de transformations peut produire un
changement significatif
• Le système se doit de toujours fonctionner suite
à chaque refactoring. Eviter les régressions.

27. Refactoring
Pourquoi?
• Améliorer la structure du logiciel
• Rendre le code plus lisible et maintenable
• Faciliter les futurs changements
• Plus de flexibilité
• Augmenter la réutilisabilité
• Faciliter la recherche de bugs

28. Refactoring
Quand?
• Code dupliqué
• Longues méthodes
• Longues liste de paramètres
• Nommage inapproprié

29. Démo