Une architecture agile et testable
- 1. Une architecture agile et testable 3 clés pour réussir l’automatisation des tests à l'échelle
- 2. $ whoami • Java, javascript, Clojure, C#, PHP • Independant, joueur d'équipe • Craftsmanship • Passionné du code et design du soft • Ouvert ! martinsson.johan@gmail.com @johan_alps
- 3. A retenir 1. Ecouter les tests - Modeler pour testabilité 2. Trois types de tests • Unit, Adapter, Application 3. Prenez le contrôle du main()
- 4. Ecouter les tests • “Sometimes we find it difficult to write a test … this usually means that our design can be improved” - S. Freeman, N. Pryce • “The tests are a canary in coal mining revealing by their distress the presence of evil design vapors” - Kent Beck
- 5. Ecouter les tests • Les tests nous disent “fais qq chose!” • A nous de trouver • Il y en a toujours • Parfois nous ne connaissons pas encore
- 6. Dogfooding
- 8. Carte • Problème! • Pyramide des tests • Adaptateurs + tests • Tests d’application + Composition root • Résultat flexible http://freeimages.com/photo/road-map-paris-119
- 9. TDD était top! • Nombre romains, FizzBuzz! • jusqu’à ce qu’on le fasse avec du vrai code.
- 10. On visait le ciel • Tester l'ensemble! • Avec vraies dépendances! • De façon rapide et fiable! • Couvrir tout
- 11. … on atterit en enfer! • Dommages collatéraux! • Evolutions => faux négatifs! • Dépendances volatiles ! • Instabilité => faux négatifs! • Lenteurs => huile sur le feu
- 12. Dommages collatéraux • Evolution données de test • Nouvelle fonctionnalité • Assertions trop strictes expect(resultFile).to.equal(referenceFile)
- 13. Dépendances Volatiles • Difficiles à initialiser, pas dispos • Etat persistant • Lents • Erratic • Debug-a-lot
- 14. Carte • Problème • Pyramide des tests! • Adaptateurs + tests • Tests d’application + Composition root • Résultat flexible
- 15. Dommages collatéraux • Solution • Tester plus bas • Assertions précises Coût de maintenance constante!
- 16. Carte • Problème • Pyramide des tests • Adaptateurs + tests! • Tests d’application + Composition root • Résultat flexible
- 17. Tests d'adaptateur • Encapsuler avec une interface minimaliste - ADAPTER • Tester à fond avec “la vraie"
- 21. Code simplifié
- 22. L'adaptateur
- 23. Tests de l'adapteur C’est testé à fond!
- 24. Avantages • Adapteurs sont (plus) faciles à tester en isolation • le reste est facile à tester - stub et mock
- 25. Inconvénients • A court d’excuses! :) • Pas de tests qui traversent la frontière
- 26. Mais encore!
- 27. Changez de techno! • Faites passer le test. • Poussez en prod!
- 28. Sert d'avertissement • Vous saurez pourquoi vos tests systèmes plantent … 10 min avant qu’ils tournent! • Debug • Pas pollué par bugs d’autres équipes • Donnez-vos tests
- 29. Adaptateurs résumé • Faciles à tester en isolation • Changement d’outil simple • Code simplifié • Moins de debug
- 30. Résumons • Isolation des difficultées • Bas niveau couvert • Quid du • branchement? • des refactorings importants?
- 31. Carte • Problème • Pyramide des tests • Adaptateurs + tests • Tests d’application + Composition root! • Résultat flexible
- 32. Tests d'application • Sans dépendences volatiles • L’ensemble de l'appli • Facile, rapide et fiable
- 33. Tests d'application • Composition Root / Main module • 2 phases 1. Build hard-to-test objects 2. Use those to build the rest: new Application(fakeDB, fakeWSClient, tmpDir) Composition Root - Dependency Injection in .NET Main module - Bob Martin
- 34. Carte • Problème • Pyramide des tests • Adaptateurs + tests • Tests d’application + Composition root • Résultat flexible
- 35. Autre tests • Tests système complêt (frontière manquante) • UI • Micro-services? • Stress-, performance-tests => parametrer tests existants
- 36. De quoi devons nous nous isoler • Services web • Bases de données (habituellement) • Processes tierces • Serveurs d’application • IHMs • Lenteurs (frameworks injection, attentes, …)
- 37. Conclusions • Tester bas niveau • Unit & Adapter => stabilité, rapidité, isolation • Moins besoin tests haut niveau • Tester => pression code/architecture • Application malléable
- 38. A retenir 1. Ecouter les tests - Modeler pour testabilité 2. Trois types de tests • Unit, Adapter, Application 3. Prenez le contrôle du main()
- 39. Conclusions • Tester bas niveau • Unit & Adapter => stabilité, rapidité, isolation • Moins besoin tests haut niveau • Tester => pression code/architecture • Application malléable