Outils | Entreprise | Compte-rendus | Humeurs |   

15 juillet 2010

CTRL+SHIFT+G

eclipse.jpgQuand du code me parait obsolète, je vérifie qu'il n'est pas utilisé en lançant un CTRL+SHIFT+G sur mon workspace Eclipse, avant de le supprimer.

Cette manoeuvre m'a trahie plusieurs fois :

  1. la classe était instanciée dans Spring
  2. la classe était utilisée... mais sur un projet qui n'était pas ouvert dans mon workspace. Ouvrir tous les projets juste pour cela a quand même un coût non négligeable. De plus, la manoeuvre n'est pas possible quand on a plusieurs branches (les différents projets portant le même nom).
  3. la méthode était utilisée dans de l'introspection. C'est là que je me dis, décidément, la réflection pose un véritable problème pour le refactoring.

Des tests d'intégration en JUnit ou Fitnesse peuvent révéler le premier souci. On se rend compte des deux autres à un moment ou un autre mais trop tard pour facilement identifier le problème.

Lire la suite...

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

18 juillet 2009

Release >=0.97 de JMockit

JMockit est en développement actif depuis quelques mois, et une montée de version au delà de 0.96 fera échouer les tests. Certaines nouveautés du framework brise en effet l'API : https://jmockit.dev.java.net/changes.html.

Le créateur du framework est encore en train de recueillir les retours pour élaborer une documentation d'accompagnement.

Tous les tutoriaux de ce site n'ont été testés qu'avec une version inférieure ou égale à 0.96. De fait, ils ne fonctionnent peut être (probablement?) pas avec une version supérieure

Parmi les nombreuses nouveautés, il est désormais possible de mocker des méthodes du JRE et de spécifier qu'une méthode ne doit jamais être appelée.

15 mai 2009

JMockit Core | Expectations : creer une implémentation vide d'une interface?

Il y a les objets que l'on souhaite mocker parce que l'on en attend des choses (que telle méthode soit appelée, avec tel paramètre) et les objets que l'on souhaite simplement bouchonner betement, pour affranchir notre test unitaire des dépendances de l'objet testé.

Les expectations de JMockit rempliront le premier besoin. La méthode newEmptyProxy de JMockit comblera des besoins plus simples, comme celui d'avoir une implémentation vide d'une interface.

Lire la suite...

28 mars 2009

JMockit Expectation : comment mocker une méthode ?

JMockit Annotation et JMockit Core impose la définition d'une classe de mock supplémentaire. JMockit Expectation permet d'effectuer des expectations sans redéfinir de classes de mock, même s'il a d'autres limitations (l'impossibilité de mocker un constructeur par exemple, ou une methode de classe abstraite).


Documentation officielle : https://jmockit.dev.java.net/javadoc/mockit/Expectations.html

Lire la suite...

- page 1 de 2