TDD - TEST DRIVEN

DEVELOPMENTJean-Baptiste VIGNERON – 18/10/2016

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

Questionnaire•Nommez 3 pratiques (ou plus) de développement qui marchent très bien selon vous

•Nommez 3 choses à éviter lorsque l’on programme

Les tests unitaires•En programmation informatique, le test unitaire (ou T.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.)

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

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 »

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

TDD

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)

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)

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

TDD•Commencez toujours par un test automatisé qui échoue

•N’ajoutez jamais de tests sur la barre rouge•Eliminez toute duplication

DEMO