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
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 …
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"
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
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 !
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