TDD et Refactoring                     Walid                     Skouri
Plan• Introduction• L’eXtreme Programming• Les bases du TDD• Les tests unitaires• Le refactoring
Introduction
Introduction• Introduction• L’eXtreme Programming• Les bases du TDD• Le refactoring
Introduction• Les démarches traditionnelles  – spécification > conception > réalisation > validation         – Concentre l...
IntroductionAccepter ce changment• C’est une composante incontournable de  tout projet• Approche XP
eXtreme Programming
XPL’idée• Réduction significative de la durée du cycle  de développement:  – Réduction du temps entre :     • L’implémenta...
XPComment• On ne fait de conception que pour les fonctionnalités  existantes, pas pour les fonctionnalités futures:  – On ...
XPPrincipaux éléments de fonctionnement de XP• Cycles itératifs pilotés par le client : Le projet progresse au rythme dité...
XP    Le coût des changements                              Traditionnel Coût deschangement     s                          ...
XPLes valeurs de XP• Communication : XP favorise le contact humain, la communication directe, plutôt que le cloisonnement ...
Les bases du TDD
Les bases du TDDTests au début du développement              Ecriture des             Ecriture du                  tests  ...
Les bases du TDDDéveloppements pilotés par les tests       Code                      Tests       propre                   ...
TDD
Les bases du TDD Recommandations• Ne jamais écrire de code sans avoir de  tests qui échouent• Les tests doivent être repré...
Les test unitaires
Les tests unitaires• Il permettent  – De contrôler et conserver la qualité du produit tout    au long du projet  – De se f...
Les tests unitairesTestabilité du code• Privilégier la composition à l’héritage• Isoler les dépendances• Injecter les dépe...
Les tests unitaires  Testabilité du code• Privilégier la composition à l’héritage                                   Hérita...
Les tests unitaires Testabilité du codeInjection de dépendance• Se rapporte à la fourniture dune dépendance  externe à un ...
Les tests unitaires  Testabilité du codeInjection du constructeurpublic class ImportantClass {             public class Im...
Refactoring
Refactoring C’est quoi?• C’est une technique de restructuration du  code existant: modifier sa structure sans  changer son...
Refactoring C’est quoi?• Chaque transformation (ou Refactoring) ne  modifie qu’une petite partie du code mais un  ensemble...
Refactoring  Pourquoi?• Améliorer la structure du logiciel• Rendre le code plus lisible et maintenable• Faciliter les futu...
Refactoring Quand?• Code dupliqué• Longues méthodes• Longues liste de paramètres• Nommage inapproprié
Démo
Prochain SlideShare
Chargement dans…5
×

TDD (Test Driven Developement) et refactoring

1 094 vues

Publié le

Présentation à la nAcademy (Janvier 2012) : Retour d'expérience sur le TDD (Test Driven Developement) et refactoring par Walid Skouri

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 094
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
24
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

TDD (Test Driven Developement) et refactoring

  1. 1. TDD et Refactoring Walid Skouri
  2. 2. Plan• Introduction• L’eXtreme Programming• Les bases du TDD• Les tests unitaires• Le refactoring
  3. 3. Introduction
  4. 4. Introduction• Introduction• L’eXtreme Programming• Les bases du TDD• Le refactoring
  5. 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. 6. IntroductionAccepter ce changment• C’est une composante incontournable de tout projet• Approche XP
  7. 7. eXtreme Programming
  8. 8. XPL’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. 9. XPComment• 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 nintroduit pas doptimisations si elles ne sont pas demandées par le client.• Priorité : – Travail actuel bien fait : Code testé, simple, lisible et sans duplication
  10. 10. XPPrincipaux éléments de fonctionnement de XP• Cycles itératifs pilotés par le client : Le projet progresse au rythme dité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 lensemble 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 quils conçoivent, et ils sappuient sur ces tests pour affiner et améliorer sans cesse la conception de lapplication sans craindre de régression.
  11. 11. XP Le coût des changements Traditionnel Coût deschangement s XP Temps
  12. 12. XPLes 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 douvrage, les testeurs sont intégrés à léquipe de développement, etc.• Feedback : quil sagisse dité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 ditération offrent à léquipe le moyen de prendre du recul sur son fonctionnement et de lamé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 loutil fabriqué (la mécanique de planification incite le client à focaliser les efforts sur les fonctions prioritaires) ou encore la conception de lapplication (guidée par un principe de « You aint gonna need it »).
  13. 13. Les bases du TDD
  14. 14. Les bases du TDDTests au début du développement Ecriture des Ecriture du tests code Tests Commencer Fini échoués
  15. 15. Les bases du TDDDéveloppements pilotés par les tests Code Tests propre échoués Refactoring Tous les tests réussis
  16. 16. TDD
  17. 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. 18. Les test unitaires
  19. 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. 20. Les tests unitairesTestabilité du code• Privilégier la composition à l’héritage• Isoler les dépendances• Injecter les dépendances
  21. 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. 22. Les tests unitaires Testabilité du codeInjection de dépendance• Se rapporte à la fourniture dune dépendance externe à un composant logiciel.• Formes d’injection de dépendance – interface injection – setter injection – constructor injection
  23. 23. Les tests unitaires Testabilité du codeInjection du constructeurpublic 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. 24. Refactoring
  25. 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. 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. 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. 28. Refactoring Quand?• Code dupliqué• Longues méthodes• Longues liste de paramètres• Nommage inapproprié
  29. 29. Démo

×