Le document présente le développement dirigé par les tests (TDD) comme une méthode de développement qui consiste à écrire des tests avant le code de production pour garantir un code propre et bien structuré. Il explique le processus du TDD en trois phases : analyse, écriture de tests, et refactoring, tout en soulignant les avantages tels que la réduction des bogues et l'émergence d'une documentation automatique. En outre, il aborde les difficultés rencontrées lors de l'implémentation du TDD, notamment avec le code hérité et la nécessité de mieux maîtriser le code produit.

1. Test Driven Development
Agile Testing Day

2. Aurélien GALTIER
Software Craftsman
Consultant/Formateur web et mobile
Twitter : @AurélienGaltier
Blog : http://blogs.developpeur.org/agaltier/

3. TDD c’est quoi ?
Moi : TDD c’est quoi ?
Collègue : On crée les tests avant de créer le code de production
″
‶

4. TDD c’est quoi ?
• Une méthode de développement
• Un outil de clean code
• Un concept test first
• Une philosophie

5. T comme Test
• On commence par les tests
• Chaque test représente un cas d’utilisation
• L’ensemble des tests représente une description de notre code
• Filet de sécurité

6. D comme Driven
• Nos tests influencent le code
• Classes
• Méthodes
• …
• Adapté directement aux tests
• Injection
• Interface
• Abstraction
• …

7. D comme development
• Parce que l’on est développeur
• Code de production
• Clean code
• Refactoring

8. Phases du TDD
Analyse
Red
Green
Refactor
Red
GreenRefactor

9. Analyse
• Analyser le besoin métier
• Mettre à jour la liste de tests
• Ecrire le nom de nos tests
• Choix du prochain test à implémenter
Analyse

10. Analyse : Ecrire le nom du test
• Le pattern Should / When
Should return I When convert 1 in roman number
Should return IV When convert 4 in roman number
Analyse

11. Analyse : Ecrire le nom du test
• Le cas du And
Should return I and log convert of 1 When convert 1 in roman
number
Should return I When convert 1 in roman number
Should log convert of 1 When convert 1 in roman number
Analyse

12. Analyse : Choisir son premier test
• Choisir votre prochain test :
• Choisir le plus petit incrément
• Un incrément qui apporte de la valeur
• Un cas à la marge
Analyse

13. Red
• Ecriture du test
• Compilation du code
• Exécution du test et voir qu'il passe au rouge
Red

14. Red : Règle des 3 A
Red

15. Red : Exécution du test
Red

16. Green
• Implémentation du code
• Respecter seulement le besoin du test
Green

17. Green
Green

18. Refactor
• Interaction sur le code
• Maîtrise du code
• Factoriser
• Structurer
• Renommer
• Pattern
• Design
Refactor

19. Refactor
• Le code de production
• Le code des tests
Refactor
“Always leave the campground cleaner than you found it.”
The Boy Scout Rule (by Uncle Bob)

20. On recommence
• On recommence à la phase d’Analyse
• On ajoute 1 test
• On implémente notre nouveau test
• On « refactor» l’ensemble du code
TDD

21. On recommence
• Développement par Cycle
• Itération de code
• Feedback rapide
• Emergence du code
TDD

22. Démonstration
• Roman Numerals
1
5
10
50
100
500
1000
I
V
X
L
C
D
M

23. Difficulté du TDD
• Coût
• D’apprentissage
• De développement

24. Difficulté du TDD
• Code legacy
• Non adapté aux tests
• Refactoring difficile

25. Difficulté du TDD
• Vous ne maîtrisez pas toujours le code
• On oublie la phase de Factorisation
• On ne prend pas de recul sur le code

26. Pourquoi faire du TDD
• Code couvert par des tests
• Très peu de code inutile
• Confiance en son code

27. Pourquoi faire du TDD
• Réduction du debug
• Développement itératif
• Feedback rapide
• Moins de F5

28. Pourquoi faire du TDD
• Emergence d’une documentation automatique
• Noms des tests parlants
• Les tests couvrent des cas d’utilisation

29. Comment faire ?
• Coding Dojo
• Kata
• Pratiquer