rice Dutheil est indépendant, membre du groupe des Zindeps. Comiteur sur Mockito.Son blog est le “TheCoffeeWorkshop“. Son Twitter est @BriceDutheil. Le design par le test Le TDD est aujourd’hui une pratique reconnue pour permettre la production de code avec peu d’anomalies. Mais ce n’est pas le seul interet du TDD ; le design du code peut en etre le grand gagnant. Ces quelques slides vont essayer de donner un apercu des opportunites à saisir et des pieges à eviter ; Mockito inside.

1. Design + tests (TDD)
 Mockito inside.

2. TDD ; en général
C’est quoi le TDD ?
=> Test Driven Development
Quels avantage à cette pratique ?
précise les spécifications du code
permet d’utiliser le programme avant qu’il soit même
écrit
augmente la confiance pour le refactoring
valide la conformité du code

3. TDD ; pour le design
Quels avantages à plus long terme ?
Moins de bugs techniques + plus de bugs
métier, sur les specs.
Évolutivité et maintenance moins
couteuse.
Confort du code

4. TDD ; une évolution de la pratique
dans le temps
 Spécifications &  … specs / exigences /
exigences conformité
 Codage du test  Design du code
 Codage des  Design du test
fonctionnalités  API
 Intéressé par la
conformité
Débutant Expérimenté

5. TDD ; une évolution de la pratique
dans le temps
 Spécifications &  … specs / exigences /
exigences conformité
 Codage du test  Design du code
 Codage des  Design du test
fonctionnalités  API
 Intéressé par la
conformité
Débutant Expérimenté

6. Un bon design
 Dans un langage objet
 Pour quelle audience ?
 Comment y arriver ?
 Avec quels outils ?

7. Dans un langage OO
 À quoi somme nous habitué ?
 À un graphe d’objet
 Construction hiérarchique de structure
 Très souvent une structure de données seules
qui est baladé par d’autres objets sans état. =>
Transaction Script
 Nous sommes habitués à une approche
ontologique dans le design d’un système.

8. The big idea of object oriented
programming
 The big idea is "messaging"
 The key in making great and growable systems is much
more to design how its modules communicate rather than
what their internal properties and behaviors should be.
 Alan Kay
 Un des père de la programmation orientée objet, un des
père de SmallTalk
 Mockito permet de se focaliser sur les interactions

9. Pour quelle audience ?
 Un bon design ok, mais qui est
intéressé ?
 Est-ce que les intérêts sont les mêmes
?
 Pour les auteurs?
 Pour les utilisateurs ?

10. Pour quelle audience ?
 Un bon design ok, mais qui est intéressé,
qui devrait être intéressé ?
 Dev, Archi, Manager, Client
 Est-ce que les intérêts sont les mêmes ?
 Pour les auteurs?
○ Dev de framework / lib :
Favoriser l’extensibilité, la réutilisation, le confort,
facile à corriger
 Pour les utilisateurs ?
○ Utiliser un code facile à comprendre, facilement
extensible, corrigeable

11. Pour quelles audiences ?
 Pour un dev de lib / de framework
 En particulier pour le développement Open Source, problème
du temps libre !
 On a les même problèmes qu’un manager sur le cycle de vie
d’un projet : le temps c’est de l’argent
 Pour l’utilisateur, un bon design lui fait gagner en
efficacité
 API lisible et expressive (!= verbeux) ; un développeur passe
en général plus de temps à lire du code qu’a en écrire!
 API ouverte aux extensions, plus facile à developper, remplacer
du code
 Le dev d’une lib ou d’un framework doit aussi être
utilisateur de celle-ci.
 Le test aide très tôt dans le développement.

12. Avec quels outils ?

13. Avec quels outils ?
 Pourquoi Mockito plus que les autres ?
 Framework de mock avec une API simple et propre
 Rapport d’erreur de premier ordre
 Support de l’approche BDD
 Super javadoc
 Pleins de features
 Easymock
 API plus verbeuse, et un peu plus intrusive
 Moins de features
 Powermock
 Très bon framework, mais plus complexe à mettre en œuvre (pour
l’auteur et pour les utilisateurs)
 Dangereux pour le design : tests boite blanche
 OK pour le legacy
 L’auteur lui-même recommande Mockito

14. Améliorer le design
 Le design est une approche pour
contrôler la complexité d’un projet
 Ses outils : patterns et principes
○ GRASP
○ GoF
○ SOLID
 Aux anti-patterns et lois
○ Par ex : The Law of Leaky Abstractions

15. Améliorer le design
 Petit focus sur ‘High Cohesion’
 C’est avoir des méthodes qui ont en commun un ou quelques
concepts seulement
 Cette mesure s’appelle LCOM
○ Si elle est trop haute => refactoring (découpage des
fonctionnalités, introduction de collaborateur, …)
 Low Coupling
 Couplage : C’est d’avoir trop de dépendances
○ Imports, Paramètres
 Mais pas que :
○ Héritage, Temporel, Flow
 Impact fort sur les tests
○ En TDD le couplage rajoute très vite de la pénibilité => refactoring

16. Améliorer le design
 Les closures
 Petits objets facilement externalisables
 Facilement testables
 Sur les clients de ces closures.
 Moins de chose à tester parce que
○ le reste du code est testé
○ surtout ce n’est plus sa responsabilité (SRP)

17. Améliorer le design
 Donnez un peu d’amour aux tests
 Si vous refactorez, pensez à
 alléger vos test
 relaxer le test
 se focaliser sur le scénario du test ET la responsabilité
du code testé
 Pour vos objets de données
 Pattern des Value Object en DDD (instanciable avec un
constructeur)
 Factory Method
accountWith("bob", "lee", 100023348.23D)
 Builder à la Joshua Bloch

18. Améliorer le design
 Les tests aussi ont leurs anti-patterns aka
Test Smell
 James Carr en a fait une liste
○ Excessive Setup
○ The Liar
○ The Free Ride
○ …
 Pour les mocks
○ The Mockery
○ Don’t mock value object
○ Don’t mock types you don’t own

19. Publicité

20. À lire + sources
 Anti-patterns de test par James Carr
http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/
 Growing Object Oriented Software Guiged by Tests
http://www.amazon.fr/Growing-Object-Oriented-Software-Guided-
Tests/dp/0321503627
 Échanges sur Hotspot en 98 avec Alan Kay
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-
October/017019.html
 Étude de productivité de logiciel OO
http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-
%20printable.pdf
 Étude sur la productivité et l’efficacité avec les
langages objet
http://www.sciweavers.org/publications/study-productivity-and-
efficiency-object-oriented-methods-and-languages
 Don’t mock types you don’t own
http://davesquared.net/2011/04/dont-mock-types-you-dont-
own.html