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...
TDD ; pour le design  Quels avantages à plus long terme ?    Moins de bugs techniques + plus de bugs    métier, sur les sp...
TDD ; une évolution de la pratique      dans le temps   Spécifications &      … specs / exigences /    exigences        ...
TDD ; une évolution de la pratique      dans le temps   Spécifications &      … specs / exigences /    exigences        ...
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     ...
The big idea of object orientedprogramming   The big idea is "messaging"   The key in making great and growable systems ...
Pour quelle audience ?   Un bon design ok, mais qui est    intéressé ?   Est-ce que les intérêts sont les mêmes    ?    ...
Pour quelle audience ?   Un bon design ok, mais qui est intéressé,    qui devrait être intéressé ?     Dev, Archi, Manag...
Pour quelles audiences ?   Pour un dev de lib / de framework     En particulier pour le développement Open Source, probl...
Avec quels outils ?
Avec quels outils ?   Pourquoi Mockito plus que les autres ?       Framework de mock avec une API simple et propre     ...
Améliorer le design   Le design est une approche pour    contrôler la complexité d’un projet   Ses outils : patterns et ...
Améliorer le design   Petit focus sur ‘High Cohesion’     C’est avoir des méthodes qui ont en commun un ou quelques     ...
Améliorer le design   Les closures     Petits objets facilement externalisables     Facilement testables   Sur les cli...
Améliorer le design   Donnez un peu d’amour aux tests   Si vous refactorez, pensez à     alléger vos test     relaxer ...
Améliorer le design   Les tests aussi ont leurs anti-patterns aka    Test Smell     James Carr en a fait une liste      ...
Publicité
À lire + sources   Anti-patterns de test par James Carr    http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/   Gr...
Prochain SlideShare
Chargement dans…5
×

Mockito - Design + tests par Brice Duteil

1 162 vues

Publié le

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 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 162
Sur SlideShare
0
Issues des intégrations
0
Intégrations
33
Actions
Partages
0
Téléchargements
12
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×