Outils | Entreprise | Compte-rendus | Humeurs |   

Mot-clé - jmockit

Fil des billets - Fil des commentaires

28 août 2010

Ecrire des bons tests

tournevis.jpgDans une de ses présentations, Misko Hevery disait que la seule raison "valable" pour ne pas écrire de tests était de ne pas savoir comment faire. Plusieurs fois, j'ai cru savoir et aujourd'hui, je ne suis toujours pas sure de le faire "bien".

Lire la suite...

4 juin 2010

Session : comment écrire du code testable

 J'ai eu le plaisir d'animer la session "Comment écrire du code testable" à la conférence Agile France 2010. C'est l'heure de mettre les slides à disposition et de faire une rétrospective !

Connaître les symptômes d'un code intestable vous permettra de mieux vous en débarrasser :
  1. Un constructeur cher
  2. Des instanciations directes
  3. Des blocs statiques
  4. Une dynastie de classes
  5. Des états globaux
  6. Annuaire de service
  7. Interroger des collaborateurs
  8. Des classes hyperactives
  9. Des méthodes trop chargées
  10. Mélanger les objets valeurs et les objets services

Lire la suite...

20 janvier 2010

Tutoriel JMockit

Un petit post pour signaler que l'article "Comment tester du code intestable avec JMockit" est en ligne sur Developpez.

A la base, ce blog a été crée comme "brouillon" pour écrire des tutoriaux, en particulier sur JMockit. Entre temps, le framework a pas mal évolué. L'article de Developpez reprend les différents posts JMockit et les remet au goût du jour.

11 janvier 2010

JMockit devient beaucoup moins contraignant

Je suis en train d'écrire l'article JMockit pour developpez, en testant avec la version 0.993 et je vais de surprise en surprise. En plus d'avoir développé d'autres API (JMockit Verifications pour le BDD), d'avoir mavenisé le projet, sans parler des efforts sur la documentation, Rogerio Liesenfeld nous affranchit de toutes ces petites choses un peu barbantes qu'il ne fallait pas oublié. Par exemple

  • plus besoin de redéfinir les méthodes originales dans le tearDown
  • plus besoin de manuellement dire qu'il faut vérifier les assertions, dans les expectations comme dans les annotations.
  • plus besoin de javaagent dans la JVM

C'était possible notamment grace à l'annotation @RunWith(JMockit) sur la classe de test. Et bien, elle aussi devient superflue ! Il n'y a réellement plus rien à faire de plus :-)

JMockit était super puissant, si, en plus il devient super simple ET lisible, ça promet.

27 août 2009

JMockit : comment migrer vers la version 0.97 ou plus

Petit essai express

En suivant la documentation officielle de migration, voici ce qu'il en ressort.

Concernant le paramètre javaagent qui ne serait plus nécessaire, ce n'est pas si évident... Que ce soit avec Java 5, 6 avec ou sans la nouvelle annotation @RunWith(JMockit.class), mes tests semblent en avoir encore besoin.

Apparemment les anciens tests fonctionnent toujours, meme si c'est deprecated

Par contre, les tear down ne sont effectivement plus nécessaires (Mockit.restoreAllOriginalDefinitions() ou Mockit.tearDownMocks()) grace à l'annotation @RunWith(JMockit.class).

Migration de Laurent

On est passé de la version 0.94c à la version 0.987.

Voici notre petit retour d’expérience sur la montée de version

  • L’annotation « @MockField » est deprecated, mais on peut la remplacer directement pas l’annotation « @Mocked » (même méthodes).
  • withInstanceOf(Object) a été remplacé par withInstanceLike(Object). Pas de deprecated pour l’ancienne méthode, donc il y aura des erreurs de compilations.
  • J’ai rajouté @RunWith(JMockit.class) sur tous les tests qui utilisent Jmockit , et j’ai retiré les tearDown è ca marche parfaitement
  • Conflit avec Twip : comme on ne peut avoir plus d’un @RunWith en JUnit. Donc j’ai du mettre mes tests twips dans une autre classe. Donc on ne peut faire une méthode de test qui utilise twip et jmockit en même temps.
  • Quelques corrections et évolutions intéressantes

o Repeat(0) : permet de tester qu’une méthode n’est pas appelée
o Les contructeurs sont plus facilement mockable via @Mocked (cf javadoc)

  • On peut toujours passer par le –javaagent OU mettre dans le classpath « <jdkHome_6.0>/lib/tools.jar » pour les tests (cf https://jmockit.dev.java.net/tutorial.html ). Pas super souple L
  • GROS problème avec maven en Java 6.

o Comme mockit embarque (directement dans le jar) les matchers Hamcrest et que Junit fait de même, lors de la compilation des tests via maven, il a des erreurs.
+ La version de hamcrest utilisé par jmokit est la 1.2 (Release 0.985 è https://jmockit.dev.java.net/changes.html), et de Junit 4.7 est la 1.1.
+ La version 1.2 de hamcrest est en téléchargement sur leur site mais sur aucun répository à cette date
o Pour résoudre le problème, on a créé un jar mockit-without-hamcrest-0.987 dans lequel on a retiré les classes de hamcrest. C’est bourrin mais ca marche J

- page 1 de 3