How to easily test at all levels. And how to get flexible architecture by listening to the need for testability

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

7. http://goo.gl/E655Qm

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"

18. Adapter
Interfaces
Adapters

19. Web!
Service X
Message!
queue

20. Adapter
Adapter!
test

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