Le document explique le développement piloté par les tests (TDD), qui consiste à écrire des tests unitaires avant le code pour favoriser la qualité du logiciel. Il couvre également le mouvement 'software craftsmanship', des pratiques recommandées comme la refactorisation de code, et les principes de 'clean code'. Enfin, il détaille la méthodologie TDD en trois étapes : écrire un test unitaire défaillant, coder pour le faire passer, puis refactoriser.

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