Download - Mockito - Design + tests par Brice Duteil
Design + tests (TDD)
Mockito inside.
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
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
TDD ; une évolution de la pratique
dans le temps
Débutant Expérimenté
Spécifications &
exigences
Codage du test
Codage des
fonctionnalités
Intéressé par la
conformité
… specs / exigences /
conformité
Design du code
Design du test
API
TDD ; une évolution de la pratique
dans le temps
Débutant Expérimenté
Spécifications &
exigences
Codage du test
Codage des
fonctionnalités
Intéressé par la
conformité
… specs / exigences /
conformité
Design du code
Design du test
API
Un bon design
Dans un langage objet
Pour quelle audience ?
Comment y arriver ?
Avec quels outils ?
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.
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
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 ?
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
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.
Avec quels outils ?
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
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
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
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)
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
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
Publicité
À 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