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.
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.
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
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