JMockit utilise l'instrumentation pour pouvoir mocker des classes, des méthodes statiques, des blocs statiques, des méthodes privées... mais alors on peut TOUT mocker avec jmockit ?! Ah non, pas tout : jusque la version 0.97, les classes java du JRE comme Collections ne le sont pas facilement par exemple (c'est normalement possible mais je n'ai pas réussi jusqu'ici).

Les personnes qui ne sont pas familières avec les tests unitaires peuvent se mettre à niveau.

Le site officiel de JMockit comporte relativement peu de documentation, c'est sur la javadoc qu'il faut s'appuyer pour tout renseignement.

ATTENTION 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

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.