Le document explore le développement piloté par les tests (TDD) et ses avantages en matière de spécifications, de conception et de maintenance du code. Il aborde également l'importance d'un bon design orienté objet, les outils comme Mockito pour faciliter le test, et les principes de cohésion et de couplage. Enfin, il met en lumière les défis du développement de bibliothèques et de frameworks, ainsi que divers anti-patterns associés aux tests.

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