[Agile Testing Day] Test Driven Development (TDD)
Télécharger en tant que PPTX, PDF0 j'aime435 vues
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.
[Agile Testing Day] Test Driven Development (TDD)
- 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
- 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
- 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