2. David Gageot
CTO Algodeal.com
«The Crowd Sourced Quant
Hedge Fund»
@dgageot
javabien.net
3. Dans la salle :
Tests unitaires ?
Couverture >50% ?
TDD ?
Mocks ?
Photo: http://www.flickr.com/photos/91082225@N00/3271601712
4. Fini...
Le code modifié
pour être testable.
Les frameworks de
mocks verbeux.
La réécriture des tests
quand le code change.
L'écriture de helpers/builders
rien que pour les tests.
5. Dummy object
« Objet passé en argument mais jamais utilisé »
Fake Object
« Implémentation simplifiée suffisante pour les tests »
Stub
« Réponses pré-programmées et parfois une mémoire »
Mock
« Contrat de collaboration »
6. Le match
Mocks
à la main
Contre
Photo: http://lh4.ggpht.com/_hViQXCC13cs/Sg21-wh7znI/AAAAAAAAA48/Piztq3c9cwE/s288/DSCN3658.JPG
9. Dummy avec Mockito
Pas de NullPointerException.
Indépendant de l’évolution constructeur.
Fonctionne avec les interfaces et les classes.
Pas Moins de
besoin de tests qui
Plus changer le
robuste changent
code pour le quand le code
rendre testable change
11. Fake Object
« Implémentation simplifiée suffisante pour les tests »
L’implémentation simplifiée peut être +/- complexe :
HashMap pour une base clef/valeur.
Base de données mémoire pour remplacer mysql.
12. Fake avec Mockito
Pas le rôle d’un framework de Mocks.
Sauf si le fake n’a pas de mémoire :
Pas
besoin de
changer le Plus facile à
code pour le maitriser
rendre testable
18. Mock
« Vérification de comportement et d'interactions »
Pas Moins de
besoin de tests qui
Pas besoin de changer le
classe de test changent
code pour le quand le code
rendre testable change
22. Robuste Lisible Compact
Moins de Pas
besoin de Pas d’
tests qui implémentation
changent changer le
code pour le classe pour
quand le code les tests
change rendre testable
23. Kung Fu avec Mockito.
Photo: http://upload.wikimedia.org/wikipedia/commons/d/dd/Wooden-dummy.jpg