Mockito - Design + tests par Brice Duteil

1,051 views
933 views

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,051
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Mockito - Design + tests par Brice Duteil

  1. 1. Design + tests (TDD) Mockito inside.
  2. 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. 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. 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. 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. 6. Un bon design Dans un langage objet Pour quelle audience ? Comment y arriver ? Avec quels outils ?
  7. 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. 8. The big idea of object orientedprogramming 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. 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. 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. 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. 12. Avec quels outils ?
  13. 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. 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. 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. 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. 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. 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. 19. Publicité
  20. 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

×