TDD et Refactoring
Walid Skouri
Plan
• Introduction
• L’eXtreme Programming
• Les bases du TDD
• Les tests unitaires
• Le refactoring
2
Introduction
3
Introduction
• Introduction
• L’eXtreme Programming
• Les bases du TDD
• Le refactoring
4
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é
5
Introduction
Accepter ce changment
• C’est une composante incontournable de tout projet
• Approche XP
6
eXtreme Programming
7
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
8
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
9
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.
10
XP
Le coût des changements
11
Coût des changement
s
Temps
Traditionnel
XP
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 »).
12
Les bases du TDD
13
Les bases du TDD
Tests au début du développement
CommencerTests
échouésFini
Ecriture des tests
Ecriture du code
14
Les bases du TDD
Développements pilotés par les tests
Code propre
Tests échoués
Tous les tests
réussis
Refactoring
15
TDD
16
Les bases du TDD
• Ne jamais écrire de code sans avoir de tests qui échouent
• Les tests doivent être représentatifs des spécifications
17
Recommandations
Les test unitaires
18
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
19
Les tests unitaires
• Privilégier la composition à l’héritage
• Isoler les dépendances
• Injecter les dépendances
20
Testabilité du code
Les tests unitaires
• Privilégier la composition à l’héritage
– 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
Héritage Composition
class Fruit { //... } class Apple extends Fruit { //... }
class Fruit { //... } class Apple { private Fruit fruit = new Fruit(); //... }
21
Testabilité du code
Les tests unitaires
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
22
Testabilité du code
Les tests unitaires
Injection du constructeurpublic class ImportantClass {
IFoo foo;
public ImportantClass()
{
this.foo = new EnterpriseFoo();
}
void doReallyImportantStuff() {
this.foo.bar();
}
}
public class ImportantClass {
IFoo foo;
public ImportantClass(IFoo foo) {
this.foo = foo;
}
void doReallyImportantStuff() {
this.foo.bar();
}
}
23
Testabilité du code
Refactoring
24
Refactoring
• 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
25
C’est quoi?
Refactoring
• 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.
26
C’est quoi?
Refactoring
• 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
27
Pourquoi?
Refactoring
• Code dupliqué
• Longues méthodes
• Longues liste de paramètres
• Nommage inapproprié
28
Quand?
Démo
29