Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Human Talks Grenoble - 11/12/2012 - TDD

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité

Consultez-les par la suite

1 sur 45 Publicité

Human Talks Grenoble - 11/12/2012 - TDD

Télécharger pour lire hors ligne

Diaporama de la présentation "TDD ou comment coder à l'endroit" jouée au Human Talks de Grenoble le 11/12/2012

Diaporama de la présentation "TDD ou comment coder à l'endroit" jouée au Human Talks de Grenoble le 11/12/2012

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Human Talks Grenoble - 11/12/2012 - TDD (20)

Human Talks Grenoble - 11/12/2012 - TDD

  1. 1. GRENOBLE TDD ou comment coder à l'endroit Xavier NOPRE – 11/12/2012
  2. 2. C'est quoi les tests unitaires?
  3. 3. C'est quoi les tests unitaires ?  Du code pour tester du code  Tests sur une "unité" de programme = partie de code la plus petite ayant une cohérence fonctionnelle  Classe  Automatisables, automatisés  Porter l'attention sur le ROI
  4. 4. C'est quoi les tests unitaires ?  Du code pour tester du code  Tests sur une "unité" de programme = partie de code la plus petite ayant une cohérence fonctionnelle  Classe  Automatisables, automatisés  Porter l'attention sur le ROI Mike Cohn
  5. 5. Pourquoi les tests unitaires?
  6. 6. Pourquoi les tests unitaires ?  Un code qui marche  Un code qui fait ce qu'il faut  Non régression
  7. 7. Pourquoi les tests unitaires ?  Diminuer les coûts Tests unitaires Scott Ambler
  8. 8. Pourquoi les tests unitaires ?  Permettre des changements courageux
  9. 9. Pourquoi les tests unitaires ?  Permettre des changements courageux  Refactorings
  10. 10. Pourquoi les tests unitaires ?  Permettre des changements courageux  Refactorings  Développement itératif & incrémental
  11. 11. Pourquoi les tests unitaires ?  Permettre des changements courageux  Refactorings  Développement itératif & incrémental  Agilité
  12. 12. Pourquoi les tests unitaires ?  Documentation du code
  13. 13. Pourquoi les tests unitaires ?  Documentation du code  Aide à comprendre l'usage de la classe
  14. 14. Pourquoi les tests unitaires ?  Documentation du code  Aide à comprendre l'usage de la classe  Aide à comprendre ce que fait le code
  15. 15. C'est quoi TDD ?
  16. 16. C'est quoi TDD ?  "Test Driven Development" = "Développement piloté par les tests"  Ecrire le code de test avant le code de production
  17. 17. C'est quoi TDD ?  "Test Driven Development" = "Développement piloté par les tests"  Ecrire le code de test avant le code de production Mais pas que …
  18. 18. Pourquoi le TDD ?
  19. 19. Pourquoi le TDD ?  Code puis tests © @jbrains
  20. 20. Pourquoi le TDD ?  Code puis tests © @jbrains
  21. 21. Pourquoi le TDD ?  Code puis tests © @jbrains
  22. 22. Pourquoi le TDD ?  Design puis Tests-Code © @jbrains
  23. 23. Pourquoi le TDD ?  Design puis Tests-Code © @jbrains
  24. 24. Pourquoi le TDD ?  Design puis Tests-Code © @jbrains
  25. 25. Pourquoi le TDD ?  Analyse puis Tests-Code-Design © @jbrains
  26. 26. Pourquoi le TDD ?  Analyse puis Tests-Code-Design © @jbrains
  27. 27. Pourquoi le TDD ?  Analyse puis Tests-Code-Design © @jbrains
  28. 28. Pourquoi le TDD ?  Aide à la conception
  29. 29. Pourquoi le TDD ?  Aide à la conception  Se soucier d'abord de l'usage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à l'architecture et à la conception  priorité aux nommages et signatures
  30. 30. Pourquoi le TDD ?  Aide à la conception  Se soucier d'abord de l'usage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à l'architecture et à la conception  priorité aux nommages et signatures  Se soucier ensuite du résultat à produire Ne pas se soucier de l'implémentation
  31. 31. Pourquoi le TDD ?  Aide à la conception  Se soucier d'abord de l'usage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à l'architecture et à la conception  priorité aux nommages et signatures  Se soucier ensuite du résultat à produire Ne pas se soucier de l'implémentation  Approche "de l'extérieur vers l'intérieur"
  32. 32. Comment le TDD ?
  33. 33. Comment le TDD ?  Trois règles (Uncle Bob Martin)  Pas de code de production si ce n'est pour faire passer un test en échec  Un seul test en échec à la fois  Code minimum pour faire passer un test qui échouait
  34. 34. Comment le TDD ?  Le Cycle Ecriture du Refactoring test Ecriture du code de production
  35. 35. Comment le TDD ?  Le Cycle 1 cycle = qq minutes  Plusieurs cycles / heure Ecriture du Refactoring test Ecriture du code de production
  36. 36. Mise en pratique ?
  37. 37. Mise en pratique ?  Un bon outillage (dispo pour tous les langages)  Principes de conception :  Architecture évolutive ("architecture agile")  Code testable  1 classe = 1 rôle ("SRP")  Injection de dépendance …  Utilisation de mocks (= "faux" collaborateurs)
  38. 38. Mise en pratique ?  Erreurs / Pièges :  Ne pas suivre les 3 règles ou le cycle  Tests trop gros, trop complexes, inutiles, sous forme de scénarios, trop longs à exécuter  Code non lisible (test et prod)  Démarche non collective de l'équipe  Mauvais entretien collectif des tests  Manque de vision globale de l’architecture
  39. 39. Mise en pratique ?  Conseils :  Se former, se faire accompagner  S'entrainer (coding-dojo)  Commencer par des cas faciles, évidents  S'y mettre progressivement  Faire des tests "à bon escient" …  Echanger, travail d'équipe, pair- programming  Du courage, ça vaut le coup !
  40. 40. Conclusion
  41. 41. Conclusion  C'est une méthode de développement et non une "méthode de tests"
  42. 42. Conclusion  C'est une méthode de développement et non une "méthode de tests" "On ne fait plus des tests"
  43. 43. Conclusion  C'est une méthode de développement et non une "méthode de tests" "On ne fait plus des tests" "Finalement, le TDD, c'est coder …à l'endroit !"
  44. 44. MERCI  Xavier NOPRE :  Développeur logiciel Java & Web passionné depuis ~ 20 ans  Pratique et partage l’agilité depuis 2007  Indépendant. Missions :  Développements sur mesure et accompagnement de projet  En mode agile  Coaching en agilité, Scrum, et ingénierie agile @xnopre xnopre.blogspot.com
  45. 45. Références  http://spin.atomicobject.com/2012/12/06/writing-tests-is- not-tdd/  http://agilitateur.azeau.com/post/2009/03/31/Les-deux- sortes-de-TDD  http://www.jbrains.ca/permalink/how-test-driven- development-works-and-more

×