TDD (Test Driven Developement) et refactoring

1,015 views
870 views

Published on

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,015
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

×