Ce document présente les concepts des tests unitaires et du développement piloté par les tests (TDD), en soulignant l'importance de ces pratiques pour assurer la qualité du code et faciliter les changements. Il décrit également les règles fondamentales du TDD et les pièges à éviter lors de sa mise en pratique. Enfin, il met l'accent sur le fait que le TDD est une méthode de développement plutôt qu'une simple méthode de tests.

1. GRENOBLE
TDD ou comment coder à l'endroit
Xavier NOPRE – 11/12/2012

2. C'est quoi les
tests unitaires?

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. 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. Pourquoi les
tests unitaires?

6. Pourquoi les tests unitaires ?
 Un code qui marche
 Un code qui fait ce qu'il 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 l'usage de la
classe

14. Pourquoi les tests unitaires ?
 Documentation du code
 Aide à comprendre l'usage de la
classe
 Aide à comprendre ce que fait le
code

15. C'est quoi TDD ?

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. 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. 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 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. 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. 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. Comment le
TDD ?

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. 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 en
pratique ?

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
 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. Conclusion

41. Conclusion
 C'est une méthode de développement
et non une "méthode de tests"

42. Conclusion
 C'est une méthode de développement
et non une "méthode de tests"
"On ne fait plus des tests"

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. 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