Généralités

  • comment installer JMockit
  • pour chaque test, demander une restauration des définitions originales des classes est fortement conseillée :
	@After
public void tearDown() {
// to avoid pertubation on other junit test
Mockit.restoreAllOriginalDefinitions();
}

Elle garantit la non perturbation des tests entre eux.

  • chaque définition de mock ne s'applique qu'à la classe explicitement définie, pas à ses classes mères. Cela permet de donner des mocks différents aux classes de niveau différent, et de vérifier les appels entre eux (super.do())

JMockit Core

JMockit Core permet de substituer tous les appels à une classe A par une classe B qu'on définit pour les besoins du test.

JMockit Annotation

JMockit Core présente les memes possibilités que Core, avec en plus des vérifications possibles sur le nombre de fois où une méthode est appelée (invocations=X). Les méthodes mockées doit avoir l'annotation Mock. Comme les appels sont vérifiés, il devient possible de vérifier également les paramètres passés.

JMockit Expectation

Les expectations permettent de créer des mocks "inline" plutot qu'en passant par des classes (JMockit Core ou Annotations). Le code est ainsi plus lisible d'une part, d'autre part les expectations doivent être respectées à la lettre (l'ordre des appels compte). La contrepartie est que les constructeurs ne sont plus mockables, ni les blocs statiques, ni les méthodes de classe abstraites.

Prochains chapitres :

Lesson of the day: when using JMockIt to mock away a class from the JRE, the -Xbootclasspath/a option does not do anything when placed into an Eclipse launch configuration’s JVM arguments. Instead, add all classes you need (jmockit.jar and junit.jar, at least) to the Bootstrap entries on the launch configuration’s Classpath tab.

Also good to know: when replacing a protected method, the replacement method must be declared public.

et avec la version la plus récente.

Sources

Les sources des exemples, testés avec JMockit 0.94c et 0.96 sont disponibles ici.