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

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