Your SlideShare is downloading. ×
Human Talks Grenoble - 11/12/2012 - TDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Human Talks Grenoble - 11/12/2012 - TDD

704
views

Published on

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


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
704
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. GRENOBLETDD ou comment coder à lendroit Xavier NOPRE – 11/12/2012
  • 2. Cest quoi lestests unitaires?
  • 3. Cest 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 lattention sur le ROI
  • 4. Cest 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 lattention sur le ROI Mike Cohn
  • 5. Pourquoi lestests unitaires?
  • 6. Pourquoi les tests unitaires ? Un code qui marche Un code qui fait ce quil faut  Non régression
  • 7. Pourquoi les tests unitaires ? Diminuer les coûts Tests unitaires Scott Ambler
  • 8. Pourquoi les tests unitaires ? Permettre des changements courageux
  • 9. Pourquoi les tests unitaires ? Permettre des changements courageux  Refactorings
  • 10. Pourquoi les tests unitaires ? Permettre des changements courageux  Refactorings  Développement itératif & incrémental
  • 11. Pourquoi les tests unitaires ? Permettre des changements courageux  Refactorings  Développement itératif & incrémental  Agilité
  • 12. Pourquoi les tests unitaires ? Documentation du code
  • 13. Pourquoi les tests unitaires ? Documentation du code  Aide à comprendre lusage de la classe
  • 14. Pourquoi les tests unitaires ? Documentation du code  Aide à comprendre lusage de la classe  Aide à comprendre ce que fait le code
  • 15. Cest quoi TDD ?
  • 16. Cest quoi TDD ? "Test Driven Development"= "Développement piloté par les tests"  Ecrire le code de test avant le code de production
  • 17. Cest 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. Pourquoi le TDD ?
  • 19. Pourquoi le TDD ? Code puis tests © @jbrains
  • 20. Pourquoi le TDD ? Code puis tests © @jbrains
  • 21. Pourquoi le TDD ? Code puis tests © @jbrains
  • 22. Pourquoi le TDD ? Design puis Tests-Code © @jbrains
  • 23. Pourquoi le TDD ? Design puis Tests-Code © @jbrains
  • 24. Pourquoi le TDD ? Design puis Tests-Code © @jbrains
  • 25. Pourquoi le TDD ? Analyse puis Tests-Code-Design © @jbrains
  • 26. Pourquoi le TDD ? Analyse puis Tests-Code-Design © @jbrains
  • 27. Pourquoi le TDD ? Analyse puis Tests-Code-Design © @jbrains
  • 28. Pourquoi le TDD ? Aide à la conception
  • 29. Pourquoi le TDD ? Aide à la conception  Se soucier dabord de lusage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à larchitecture et à la conception  priorité aux nommages et signatures
  • 30. Pourquoi le TDD ? Aide à la conception  Se soucier dabord de lusage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à larchitecture et à la conception  priorité aux nommages et signatures  Se soucier ensuite du résultat à produire Ne pas se soucier de limplémentation
  • 31. Pourquoi le TDD ? Aide à la conception  Se soucier dabord de lusage de notre classe Nous allons passer du temps à utiliser notre classe :  priorité à larchitecture et à la conception  priorité aux nommages et signatures  Se soucier ensuite du résultat à produire Ne pas se soucier de limplémentation  Approche "de lextérieur vers lintérieur"
  • 32. Comment le TDD ?
  • 33. Comment le TDD ? Trois règles (Uncle Bob Martin)  Pas de code de production si ce nest pour faire passer un test en échec  Un seul test en échec à la fois  Code minimum pour faire passer un test qui échouait
  • 34. Comment le TDD ? Le Cycle Ecriture du Refactoring test Ecriture du code de production
  • 35. Comment le TDD ? Le Cycle 1 cycle = qq minutes  Plusieurs cycles / heure Ecriture du Refactoring test Ecriture du code de production
  • 36. Mise enpratique ?
  • 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. 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. Mise en pratique ? Conseils :  Se former, se faire accompagner  Sentrainer (coding-dojo)  Commencer par des cas faciles, évidents  Sy mettre progressivement  Faire des tests "à bon escient" …  Echanger, travail déquipe, pair- programming  Du courage, ça vaut le coup !
  • 40. Conclusion
  • 41. Conclusion Cest une méthode de développement et non une "méthode de tests"
  • 42. Conclusion Cest une méthode de développement et non une "méthode de tests" "On ne fait plus des tests"
  • 43. Conclusion Cest une méthode de développement et non une "méthode de tests" "On ne fait plus des tests" "Finalement, le TDD, cest coder …à lendroit !"
  • 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. 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