Spock-(2/X) – Spock, EasyMock et Mockito sont sur un bateau
On a vu dans la première partie que l’on pouvait faire facilement du data-driven testing et que la syntaxe en bloc apportait beaucoup en lisibilité. Les blocs expect/where que l’on a vu sont les plus adéquats lors de cas de tests simples, où l’on peut facilement exprimer le stimulus et son résultat, typiquement monojbetA.maMethode()==monResultat. Dans le cas où l’on se retrouve face à des tests un peu plus compliqués, l’utilisation de la structure given/when/then est alors préférable. Cet article n’a pas pour vocation de comparer les fonctionnalités des trois frameworks, juste de présenter spock et de comparer la syntaxe des trois frameworks dans le cas de tests ‘classiques’.
Test given/when/then
En effet, un bloc then permet de déclarer des conditions, des exceptions, des interactions et des définitions de variables là où un bloc expect ne peut contenir que des conditions et des déclarations de variables. L’écriture given/when/then est également plus intuitive dans le cas où vous souhaitez tester des stories. C’est également une des clés du Behavior Driven Development et une méthode saine pour structurer ses tests, qui oblige à réfléchir vraiment à ce que l’on teste. Ce que j’aime chez spock, c’est que c’est obligatoirement intégré via ces blocs, on ne peut pas faire autrement 
Test condition simple – comportement
Spock permet le data-driven testing mais c’est également un framework facilitant la création de bouchons/simulacres [Plus d'infos sur les différences bouchon/simulacre et test d'état/de comportement]. On s’intéresse ici au le test par comportement, c’est à dire qu’on va s’occuper des chainages des appels des méthodes entre elles et moins du résultat. On cherche alors à vérifier que l’appel à spockResource.findCalendarByDay(’1′) entraîne bien un unique appel à calendarDao.getInfosByDay(’1′).
def "test par comportement"() {
given:
def calendarDao = Mock(CalendarDao)
def spockResource = new SpockResource(calendarDao)
when :
spockResource.findCalendarByDay("1")
then :
1 * calendarDao.getInfosByDay("1")
}
Le bloc given permet de définir les variables nécessaires à l’exécution du test. Ici, on bouchonne le dao que l’on affecte ensuite au service que l’on souhaite tester. Le bloc when correspond à l’appel de la méthode à tester.
Le bloc then comporte ici uniquement la condition à tester. La syntaxe veut dire on vérifie que la méthode calendarDao
.getInfosByDay est appelée uniquement une fois (1 *) avec le paramètre ’1′. Les paramètres sont évalués via l’appel à la méthode equals.
A la différence d’EasyMock, qui fonctionne par défaut avec des simulacres, Spock comme Mockito renvoie de base pour toutes les méthodes mockées sans spécification null ou 0 ou false. Ici par exemple, l’appel à
calendarDao
.getInfosByDay("1")
renverra null. Pour spécifier une valeur de retour différente, il suffit d’utiliser la syntaxe suivante :
calendarDao
.getInfosByDay(_) >> new SpockInfo("1");
Le même code avec EasyMock avec une valeur de retour :
@Test
public void testEasyMock() {
//given
CalendarDao calendarDao = createNiceMock(CalendarDao.class);
SpockResourcespockResource = new SpockResource(
calendarDao);
expect(calendarDao.getInfosByDay("1")).andReturn(
new SpockInfo("1"));
replay(calendarDao);
//when
SpockInfo spockInfo= spockResource.findCalendarByDay("1");
//then
verify(calendarDao);
}
Avec EasyMock, on annote la méthode par @Test [annotation JUnit] puis on crée le mock à l’aide de EasyMock.createNiceMock, pour avoir un mock lénient. On précise ensuite que l’on s’attend à ce que la méthode calendarDao.getInfosByDay(’1′) retourne l’objet new SpockInfo(’1′) avec expect(calendarDao.getInfosByDay(’1′)).andReturn(new SpockInfo(’1′)); . On ‘charge’ ensuite les mocks via le replay et à la ligne suivante on lance l’appel à la méthode testée. Le verify à la dernière ligne permet de vérifier qu’un unique appel à la méthode a bien été effectué.
Test condition simple – état
L’inconvénient de l’utilisation des simulacres, c’est que les tests et le code testé sont très (trop!) liés. Ainsi une modification du code peut entraîner beaucoup de refactoring au niveau des tests sans valeur ajouté. L’exemple le plus marquant est la séparation d’une méthode en deux méthodes distinctes : il faut reprendre tous les simulacres alors que ce n’est qu’une modification de ‘clarté’. Il est donc souvent préférable de ne pas tester le comportement mais uniquement le résultat à chaque fois que cela est possible et judicieux, c’est à dire du faire du test sur l’état des objets.
def "test stub avec retour"() {
given:
def calendarDao = Mock(CalendarDao)
def spockResource = new SpockResource(calendarDao)
when :
def spockInfo = spockResource.findCalendarByDay("1")
then :
calendarDao
.getInfosByDay("1") >> new SpockInfo("1");
spockInfo.day == 1
}
Ici, on ne fait plus de contrôle sur le nombre d’appel à la méthode getInfosByDay(’1′). On indique juste que lorsque cette méthode est appelée, on renvoie (>>) une nouvelle instance de SpockInfo. Ici pas de assertEquals ou autre méthode du genre, le spockInfo.day==1 est en fait un raccourci pour écrire assert spockInfo.day == 1.On vérifie que la variable day de l’objet spockInfo est bien égale à 1.
Voilà le code équivalent avec Mockito :
@Test
public void testMockito() {
//Given
CalendarDao calendarDao = mock(CalendarDao.class);
SpockResource spockResource = new SpockResource(
calendarDao);
when(calendarDao.getInfosByDay("1")).thenReturn(
new SpockData("1"));
//when
SpockData spockData= spockResource.findCalendarByDay("1");
//then
assertEquals("1", spockData.getDay());
}
A la première ligne, on construit le bouchon calendarDao que l’on affecte à la ligne suivante à l’objet spockResource. On indique au bouchon calendarDao que quand la méthode getInfosByDay est appelée avec le paramètre ’1′, alors elle retourne new SpockData(’1′). On effectue ensuite l’appel à la méthode testée spockResource.findCalendarByDay(’1′) et on vérifie que la variable day du résultat spockData est bien égale à 1.
Et si on veut chainer les retours ?
Test retour multiple
Il est parfois nécessaire de renvoyer des valeurs différentes pour une même méthode bouchonnée. Pour les 3 cas suivants, le premier appel à la méthode calendarDao.getInfosByDay avec le paramètre ’1′ renverra SpockInfo(’1′), le deuxième new SpockInfo(’2′) :
Avec Easymock :
expect(calendarDao.getInfosByDay("1")).andReturn(new SpockInfo("1")).andReturn(new SpockInfo("2"))
Avec Mockito :
when(calendarDao.getInfosByDay("1")).thenReturn(new SpockData("1")).thenReturn(new SpockInfo("2"))
Avec Spock :
calendarDao.getInfosByDay("1") >>> [new SpockInfo("1"),new SpockInfo("2")];
Le prochain article abordera les fonctionnalités plus avancées de la gestion des arguments des fonctions mockées (ArgumentMatcher) également dans les trois frameworks.
Crédit Photo : Mistinguette18
Hello,
Bonne présentation, cela dit il ne faut pas oublié qu’avec mockito il est possible de déclarer les mock ou les espions dans la classe de test par @Mock et @Spy.
Mockito permet également d’injecter ces mock automatiquement (dans la mesure du possible) sur les champs de la classe de test annotés par @InjectMocks.
La prochaine version de Mockito sera capable d’instancier automatiquement les champs @Spy et @InjectMocks dont le type a un constructeur sans argument, ce sera très pratique pour les objets qui sont construit avec un monteur (par exemple le pattern Builder de Joshua Bloch).
Salut Mathilde,
Merci pour cette suite.
Je ne suis pas d’accord pour shunter un comportement, sauf s’il n’a aucune importance. L’OBJET est affaire de comportement après tout.
Souvent, appeler 2/3 fois une méthode au lieu d’une met à jour des problèmes de conception …
A mon sens le comportement de la méthode est primordial car pour N comportements on peut aboutir au même état …
Une méthode n’est pas maitrisée si le comportement n’est pas prédictible, donc testé.
Je suis d’accord avec toi Louis, mais je trouve ca plus difficile à maintenir pour peu de gain, sauf dans les cas où l’appel à certaines méthodes est critique où il vaut mieux prendre le temps.
Merci Brice, je mets à jour !