Présentation sur la méthodologie TDD (Test Driven Development) dans le cadre des Universités du Soir Océane Consulting Nord

1. TDD -TEST DRIVEN
DEVELOPMENT
Jean-BaptisteVIGNERON – 18/10/2016

2. Sommaire
• Questionnaire
• Les tests unitaires
• Le mouvement « Software Craftsmanship »
• TDD
• Démo

3. Questionnaire
•Nommez 3 pratiques (ou plus) de développement
qui marchent très bien selon vous
•Nommez 3 choses à éviter lorsque l’on
programme

4. Les tests unitaires
• En programmation informatique, le test unitaire (ouT.U.) est une procédure
permettant de vérifier le bon fonctionnement d'une partie précise d'un
logiciel ou d'une portion d'un programme.
• Chaque langage possède au moins un outil / framework de tests unitaires
(C#, Java, Ruby, PHP, JavaScript…)
• L'ensemble des tests unitaires doit être rejoué après une modification du
code afin de vérifier qu'il n'y a pas de régressions.
• Utilisation des mocks : ce sont des objets simulés qui reproduisent le
comportement d'objets réels de manière contrôlée (ex: base de données,
webservices, API, etc.)

7. Le mouvement « Software Craftsmanship »
• Complète le manifeste agile
• Proposé en 2009
• Plusieurs pratiques
• TDD
• BDD
• Legacy Refactoring
• Revues de code
• Clean code
• Pair-programming
• Principes KISS et SOLID

8. Commauté « Software Craftsmanship » à Lille
• Communauté créée en 2015 animée par Julien JAKUBOWSKI
• http://www.meetup.com/fr-FR/Software-Craftsmanship-Lille/
• Gratuit
• Meetup tous les 2 mois environ
• Réunit les différents acteurs lillois intéressés ou pratiquant le « software craftsmanship »

9. TDD
• C’est une technique qui consiste à couvrir notre programme de tests unitaires
• C’est une technique de développement
• Les tests aident à spécifier du code, et non pas à le valider
• 3 étapes pour développer une fonctionnalité ou corriger un bug
• Je pose un test unitaire et je le fais passer au rouge
• J’écris le code nécessaire pour faire passer mon test au vert
• Je nettoie mon code et le refactorise
• La couverture de code devient alors un bénéfice, et non plus un objectif
• Le vrai indicateur à regarder est : la NON-couverture de code

10. TDD

11. TDD
• TDD renverse le modèle classique
• Besoins ‐> Spécifications ‐> Codage/Tests Unitaires ‐>Tests d’intégration ‐> Maintenance
• Scénarios Utilisateurs ‐>Test/Code/Refactor ‐>Tests d’Intégration
• TDD remplace une approche « industrielle »…
• Concevoir, puis produire, puis valider, puis analyser, puis corriger
• Rationnaliser la production de code : le mieux est l’ennemi du bien
• …par une approche « artisanale »
• Le code est un matériau de production, on cherche l’excellence dans le geste
• Tester et maintenir le code au plus près de son écriture
• Principes KISS et SOLID (Clean code)

12. TDD – quelques principes de Clean code
• KISS : Keep It Simple Stupid
• SOLID
• Single Responsibility Principe : une classe doit avoir une seule responsabilité
• Open/Closed : une classe doit être ouvert à l’extension mais fermée à la modification
• Liskov Substitution : utilisez le type le plus « haut » possible (classes abstraites, interfaces…)
• Interface segregation : préférez utiliser plusieurs interfaces spécifiques pour chaque client plutôt
qu’une interface générale
• Dependency Inversion : injection de dépendances. Il faut dépendre des abstractions et non pas des
implémentations
• DRY : Don’t Repeat Yourself
• YAGNI :You ain’t gonna need it (Vous n’en aurez pas besoin)

13. TDD
• Un test contient trois parties
• Agencement (Arrange): créer un ou plusieurs objets
• Action (Act): appeler une fonction
• Assertion (Assert): comparer le résultat de l’appel avec le résultat
attendu
• Essayez de commencer par l’assertion

14. TDD
• Commencez toujours par un test automatisé qui échoue
• N’ajoutez jamais de tests sur la barre rouge
• Eliminez toute duplication

15. DEMO