Mockito - Design + tests par Brice Duteil
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Mockito - Design + tests par Brice Duteil

on

  • 955 views

rice Dutheil est indépendant, membre du groupe des Zindeps. Comiteur sur Mockito.Son blog est le “TheCoffeeWorkshop“. Son Twitter est @BriceDutheil....

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.

Statistics

Views

Total Views
955
Views on SlideShare
932
Embed Views
23

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 23

http://www.normandyjug.org 23

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mockito - Design + tests par Brice Duteil Presentation Transcript

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