Rien de prévu mardi prochain ? Rejoignez nous pour la première de la marmite, LA soirée récurrente des duchesses ! J’aurais l’occasion d’animer avec Brice Dutheuil, commiter Mockito, un Hands-On sur la mise en place de tests avec Mockito et comme il y en a pour tous les gouts chez les duchesses, on a également prévu en parallèle un open-space pour échanger sur les sujets qui vous intéressent !
Qu’est-ce qu’un open space ? C’est un peu comme un barCamp à part que les sujets sont présentés au début et que l’on ne traite que les sujets les plus populaires pendant un temps limité. Le but essentiel est de partager et de débattre. Tous les sujets autour de Java et de l’IT sont les bienvenus. Pour vous donner des idées, voici quelques pistes possibles :
- une problématique technique que vous avez rencontrée
- un super outil qui a changé votre vie de développeur
- votre sujet de veille préféré
- ou une problématique relationnelle (ex: comment travailler avec une personne au caractère difficile ?).
L’article précédent a permis de comparer la syntaxe des trois frameworks sur les cas classiques. Un cas où Spock se détache vraiment des deux autres frameworks, c’est sur la gestion des arguments des méthodes mockées.
Les wildcards
Il est possible d’utiliser des wildcards au niveau des arguments appelés. Ainsi 1 * calendarDao
.getInfosByDay(_) veut dire ‘la méthode calendarDao.getInfosByDay est appelée une fois (1 *) avec n’importe quel paramètre (_). On peut également spécifier la classe de l’argument : 1 * calendarDao.getInfosByDay(_ as String) .
Il est également possible par exemple de compter le nombre d’appel aux méthodes d’un simulacre (quel quel soit : 3 * calendarDao._ passera uniquement si les instructions du bloc when font exactement appel à 3 méthodes de l’instance calendarDao. Il est également possible de donner des intervalles plutôt qu’une valeur, ce qui n’est pas permis par les autres frameworks (à part le ‘au moins 1 fois’) :
(1..3) * calendarDao.getInfosByDay(_) [entre 1 et 3 fois]
(5.._) * calendarDao.getInfosByDay(_) [=> au moins 5 fois]
(_..5) * calendarDao.getInfosByDay(_) [=> au plus 5 fois]
Il existe de nombreux wildcard, la plupart ne servent pas à grand chose. Ceux qui me semblent le plus important :
calendarDao.getInfosByDay(_) : n’importe quel argument
calendarDao.getInfosByDay(!null) : n’importe quel argument non null
calendarDao.getInfosByDay(_ as String) tous les éléments de type String
Equivalent EasyMock
expect(calendarDao.getInfosByDay((String)anyObject())) : n’importe quel argument, obligation d’être une String
expect(calendarDao.getInfosByDay((String)notNull())): n’importe quel argument non null
expect(calendarDao.getInfosByDay(isA(String.class))):tous les élements de type String
Equivalent Mockito
when(calendarDao.getInfosByDay(anyString())) : n’importe quel argument, obligation d’être une String
when(calendarDao.getInfosByDay((String)notNull())): n’importe quel argument non null
when(calendarDao.getInfosByDay(isA(String.class))): tous les élements de type String
Vous pouvez trouver la liste ici : http://code.google.com/p/spock/wiki/Interactions
Les contraintes personnalisées
Les contraintes personnalisées sont très utiles dans certains cas, par exemple lorsque la méthode equals est déjà défini dans le code et qu’elle ne correspond pas à notre besoin ou que nous avons par exemple un champ date que nous souhaitons exclure de la comparaison. En règle général, il vaut mieux redéfinir la méthode equals qui est spontannément utilisée par les 3 frameworks pour comparer l’égalité des arguments attendus et reçus.
Nous allons chercher avec les 3 frameworks à créer des contraintes personnalisés (spock) ou des argument matcher (Mockito & Easymock). Notre but est de faire en sorte que l’appel à listSpockData.add avec un paramètre ayant comme variable de classe img égale à « a » soit bien simulée. Pour cela, nous créons un objet spockData ayant bien img = « a » ainsi qu’une liste d’objets SpockData. Nous appelons ensuite la méthode listSpockData avec l’objet spockData et vérifions que cette dernière a bien été appelée.
Avec Spock :
def "should list Spock Data"() {
given:
SpockData spockData = new SpockData("a", "accroche", "details", 6);
List listSpockData = Mock();
when :
listSpockData.add spockData;
then :
1*listSpockData.add({it.img=="a"})
}
Spock permet via les conditions particulières de définir un bloc à l’aide d’une closure , avec { } et de définir à l’intérieur plusieurs conditions. It signifie ici l’objet qui sera passé en paramètre à la méthode. Il est possible d’utiliser plusieurs expression (it.img== »img »&&it.day==6) ou une fonction définie dans la classe de test.
Avec Mockito, qui utilise en fait les ArgumentMatcher du framework Hamcrest.
class isImgEqualToA extends ArgumentMatcher { //creation d un argument matcher
public boolean matches(Object spockData) {
return ((SpockData) spockData).getImg() == "a";
}
}
@Test
public void testArgumentMockito(){
List mock = mock(List.class);
when(mock.add(argThat(new isImgEqualToA()))).thenReturn(true);
mock.add(newSpockData("a", "b", "c", 2));
verify(mock).add(argThat(new isImgEqualToA()));
}
Avec Easymock, l’opération se révèle être très verbeuse. [Pour voir une implémentation plus conforme] :
static class Matcher implements IArgumentMatcher { //creation du matcher
@Override// implementer cette methode permet de definir
// un message d erreur
public void appendTo(StringBuffer arg0) {
}
@Override// definition de la methode qui verifiera que
// l argument img est bien egal a A. smell code.
public boolean matches(Object spockData) {
return ((SpockData) spockData).getImg() == "a";
}
// definition d une methode static pour déclarer le matcher
public static SpockData isImgEqualToA() {
EasyMock.reportMatcher(new Matcher());
return null;
}
}
@Test //Test
public void testArgumentEasyMock() {
List mock = createMock(List.class);
expect(mock.add(Matcher.isImgEqualToA())).andReturn(true);
replay(mock);
mock.add(new SpockData("a", "b", "c", 2));
verify(mock);
}
Les tests mockito et easymock sont bien plus verbeux et au final sont plus restrictifs car elles utilisent des classes séparées pour définir les matchers. Spock évite la lourdeur d’avoir à définir une autre classe
Néanmoins, dans le cas de tests avec ArgumentMatcher, EasyMock & Mockito permettent de définir des messages d’erreurs personnalisés, via la méthode appendTo pour le premier et describeTo pour le deuxième. Notons que pour le premier, il faut la coder nous même alors que le deuxième en propose une par défaut construite à partir du nom de la classe isImgEqualToA donne ‘Img equal to A’. En règle général, on affiche un toString() de l’objet pour aider au debuggage et on regarde alors les 2 chaînes pour trouver les différences (ou en pas à pas en debug). Spock ne propose rien de tel dans sa version actuelle (0.4) mais en version 0.5 il est prévu de pouvoir utiliser les matchers d’Hamcrest, revenant à avoir la même syntaxe qu’avec Mockito, en un peu plus courte.
Crédit Photo : Oskay – http://www.flickr.com/photos/oskay/339996940/sizes/m/in/photostream/
]]>
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
]]>
Qui n’a jamais attendu de nombreuses minutes pour builder un projet ? Et qui n’en a jamais profité pour aller boire un café/regarder twitter/… ? Parce que l’on teste fréquemment, il est important d’essayer d’optimiser et de réduire la durée d’exécution des tests. Tester souvent ne veux pas dire attendre souvent ! Il est donc primordial d’essayer de réduire cette durée en jouant sur différents paramètres. Comment obtenir le résultat des tests le plus rapidement possible ?
Ce qui suit est tiré de la conférence de David Gageot [ @dgageot / http://javabien.net ] à SoftShake 2010.
Sur une vingtaine de personnes présentes dans la salle, les durées de build vont de quelques minutes à plusieurs heures. David présente brièvement quelques frameworks comme Infinitest et JUnitMax. Ce sont des plugins pour IDE Java qui permettent de lancer les tests unitaires en continu et de manière intelligente, c’est à dire uniquement ceux impactés par le code modifié.
La première idée lorsque l’on cherche à optimiser cette durée d’exécution, c’est de vouloir déléguer le problème. C’est faire tourner les tests sur des serveurs distribués qui permettront d’exécuter les tests en tâches de fond. C’est une mauvaise idée, les serveurs coûtent chers et on peut se retrouver submerger. Il existe des méthodes plus simples pour réduire cette durée.
Le KISS ( Keep It Simple, Stupid ) est également applicable lorsque l’on crée des tests. Chercher à optimises ses tests peut améliorer votre produit : ce qui est simple à tester sera simple à coder et à utiliser. Ce qui est compliqué n’en vaut surement pas la peine.
Le tricheur
La manière la plus simple pour accélérer les tests c’est d’acheter une machine plus rapide. Exécuter les tests sur une machine plus rapide peut être un vrai gain de temps, David nous donne l’exemple d’une exécution 15% plus rapide sur la machine la plus rapide par rapport à la plus lente. Il est également possible d’utiliser la nouvelle fonctionnalité de maven de build en parallèle (mvn -T2 clean install / mvn -t4 clean install). Nous avons essayé sur un de nos projets, l’exécution du build est passé de 1m30 à 30 secondes !
Il est également possible de faire en sorte que les tâches maven surefire pour JUnit et TestNG soient exécutés en parallèle. Comme les tests se doivent d’être indépendant et isolés, ce sont de bons candidats à une exécution en parallèle. Faire quand même attention que vous pouvez vous retrouver avec des problèmes de concurrence dans certains cas.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.5</version>
<configuration>
<parallel>methods</parallel>
<threadCount>4</threadCount>
</configuration>
</plugin>
Il existe deux façons de paralléliser : méthodes ou classes. Utiliser la méthode de parallélisation par méthode peut se révéler risqué car il est fort probable que tous les tests n’auront pas été designés dans l’optique d’être exécutés en parallèle, la méthode ‘classes’ est un choix plus prudent. Plus d’infos sur le blog de Wakaleo Consulting.
Le paresseux
Il y a souvent des tests redondants dans un projets : débusquez les, cela permettra de gagner en exécution et en lisibilité. C’est tellement simple qu’on ne le fait pas ! Ne pas hésiter à supprimer des fonctionnalités et les tests associés si elles ne servent plus rien, le projet y gagnera en simplicité.
Les accès réseaux et disques sont trop lents. Il faut essayer au maximum de s’en passer et privilégier les bases de données en mémoire comme h2 (qui ressemblera plus à mysql que hsqldb). De même pour les accès mails, il est possible d’utiliser dans les tests des serveurs SMTP en mémoire comme ethereal. Si beaucoup de tests accèdent à des fichiers, Spring Resource ou Apache VFS (Virtual File System) sont de bonnes alternatives.
Le brave
Il est préférable de tester les règles métiers dans les tests unitaires plutôt que dans les test d’intégrations. Il ne faut pas confondre tests d’intégrations et tests unitaires : les premiers sont , bien qu’essentiel, plus longs à tester, ils doivent être utiliser avec parcimonie. Par exemple, pour plusieurs tests qui accèderaient à une base de données peuvent être remplacés par un test qui permet de garantir que l’on peut bien accéder à la base de données et par plusieurs autres tests où l’accès à la base de données aura été bouchonné.
Une méthode lorsque l’on cherche à diminuer la durée d’exécution de tests est de prendre le test d’intégration le plus long et de l’analyser jusqu’à réussir à le découper en un test d’intégration plus petit et plusieurs tests unitaires. Si c’est l’accès à certaines couches qui sont lentes lors de tests d’intégrations, il est recommandé de les bouchonner, les frameworks de mocks ne servent pas que dans le cas de tests unitaires
De même, méfiez vous des tests d’interface, ils prennent beaucoup de temps et souvent, ce qu’ils testent peut être tester unitairement. Selenium est à utiliser avec modération. Méfiez vous vraiment quand vous commencez à tester vos fonctionnalités via Selenium. Et ne dites pas ‘mon utilisateur veut de l’AJAX‘ ‘J’ai besoin de tester la compatibilité des différents navigateurs’.
Chaque complexité a un coût. Et cela se paye à chaque fois que les tests sont exécutés. Si c’est compliqué à tester : danger, la fonctionnalité peut sûrement être faite plus simplement. Il est possible de faire des tests unitaires en Javascript plutôt que tester dans les browsers (ex : QUnit).
David préfère limité AJAX aux réels besoins et d’effectuer au maximum le code server-side.
Et pour finir : simplifier et optimiser votre code. Ce sont des choses qui se font. Le build va être plus rapide et l’application aussi 
A vous l’effet Kiss Cool
PowerMock est une extension de 2 API bien connues des mockeurs (Ha ha), EasyMock et Mockito. Qui n’as jamais été obligé de supprimer un final, rendre une méthode private protected ou galérer sur des appels statiques pour faire ses tests ? PowerMock nous permet de « tester l’intestable » sans toucher au code. Bonne idée ? Oui, mais attention, cette bonne idée a un coût qu’il ne faut pas négliger. L’exécution des tests peut prendre jusqu’à 10 fois plus de temps.
De plus, si on ne fait pas attention, on peut tomber sur des anomalies qui peuvent être difficile à résoudre si on n’a pas saisi le « truc ». L’objet de cet article est de vous présenter ce qui me crash le plus souvent mes tests.
Le problème
Voici la classe à tester :
package fr.java.freelance;
public class UnTrucCool {
public final boolean estQuelqueChose(){
return critereUn() && critereDeux();
}
public boolean critereUn(){
return false;
}
public boolean critereDeux(){
return false;
}
}
En fait, un test existe déjà :
package fr.java.freelance;
import static org.junit.Assert.*;
import org.junit.Test;
import static org.mockito.Mockito.*;
public class UnTrucCoolTest {
@Test
public void testEstQuelqueChose() {
UnTrucCool banane = mock(UnTrucCool.class);
when(banane.critereDeux()).thenReturn(true);
when(banane.critereUn()).thenReturn(true);
assertTrue(banane.estQuelqueChose());
}
}
Pour une bonne raison, nous décidons d’utiliser PowerMock, nous modifions donc le test comme ceci :
package fr.java.freelance;
import static org.junit.Assert.*;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import static org.powermock.api.mockito.PowerMockito.*;
@RunWith(PowerMockRunner.class)
@PrepareForTest(UnTrucCool.class)
public class UnTrucCoolPMTest {
@Test
public void testEstQuelqueChose() {
UnTrucCool banane = mock(UnTrucCool.class);
when(banane.critereDeux()).thenReturn(true);
when(banane.critereUn()).thenReturn(true);
assertTrue(banane.estQuelqueChose());
}
}
Le test est strictement identique, mais ça ne fonctionne plus! estQuelqueChose() renvoie systématiquement false !
La solution
Dans le premier test nous utilisons simplement Mockito qui ne sait pas mocker les méthodes finales. Comme il ne sait pas le faire, il adopte un comportement par défaut et appel la méthode réelle. En passant à PowerMock, toutes les méthodes finales peuvent être mockées et doivent donc avoir un comportement défini explicitement. On notera que si estQuelquechose() n’avait pas été finale, le test Mockito aurait également dû définir explicitement le comportement à avoir.
@RunWith(PowerMockRunner.class)
@PrepareForTest(UnTrucCool.class)
public class UnTrucCoolPMTest {
@Test
public void testEstQuelqueChose() {
UnTrucCool banane = mock(UnTrucCool.class);
when(banane.critereDeux()).thenReturn(true);
when(banane.critereUn()).thenReturn(true);
when(banane.estQuelqueChose()).thenCallRealMethod();
assertTrue(banane.estQuelqueChose());
}
}
Faites attention lorsque vous passez un existant sur PowerMock.
]]>