Tests : Quelle est la meilleure API Java pour mettre en place des mocks (simulacres) ?

Le , par Khrono, Nouveau membre du Club
Bonjour,

Je dois utiliser les mock object. J'ai découvert qu'il y avait plusieurs API pour ça et j'aimerai savoir si vous connaissiez un comparatif sur ceci. Ou sinon me citer les connaissances ou vos expériences sur les API mock que vous utiliser.

Pour le moment easy mock a retenu mon attention car il a une documentation en français plutôt bien expliqué. Mais également JMock que j'ai pu essayer qui marche bien.

Merci d'avance .


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de michel.di michel.di - Membre éprouvé https://www.developpez.com
le 08/10/2009 à 9:22
Pour ma part j'utilise Mockito que je trouve très simple d'utilisation et de compréhension!
Avatar de asouquieres asouquieres - Nouveau membre du Club https://www.developpez.com
le 08/10/2009 à 11:47
Ayant besoin de mocker des Appels à des méthodes statiques, ou "final". Mon choix s'est porté sur PowerMock qui est au départ une extension de Easymock.

Apparemment il devient parfaitement utilisable avec Mockito aussi.

Plutot simple à utiliser, pleins d'annotation, suffisament de doc pour s'en sortir !
Avatar de foucha foucha - Membre actif https://www.developpez.com
le 14/10/2009 à 16:58
Citation Envoyé par TheNOHDirector  Voir le message
Si tu en as le besoin JMock (ou JMockit, je ne sais plus exactement) te permettra de faire de la manipulation de bytecode au niveau classe.

C'est JMockit qui le permet. Sinon powermock permet effectivement lui aussi de mocker des méthodes statiques.
Avatar de foucha foucha - Membre actif https://www.developpez.com
le 25/01/2010 à 11:48
un comparatif sur ce que chaque framework permet de faire :

http://code.google.com/p/jmockit/wik...mparisonMatrix

... sur le site de l'un d'entre eux...

Il est quand meme un minimum objectif malgré tout vu qu'il s'appuie sur des fonctionnalités possibles ou non et pas sur des critères émotionnels. Après, il faut voir si l'on a vraiment besoin de tant de choses.

++
Foucha.
Avatar de TheNOHDirector TheNOHDirector - Membre du Club https://www.developpez.com
le 25/01/2010 à 12:55
Hello,

Le lien est intéréssant, mais mockito supporte *un poil* plus de chose maintenant.

Par exemple matching poussé d'argument, ou les vérifications dans l'ordre (même partielles). Il suffit de savoir utiliser l'API.

Il ne parle pas non plus du style de l'API, typiquement l'approche de jmockit et de mockito sont différentes. D'une manière générale l'approche BDD de mockito est plutôt bienvenue. Alors que l'approche jmockit est plus sombre/encombrée pour un langage comme Java.
Évidement dans la vraie vie ça dépend quand même du test.
Avatar de foucha foucha - Membre actif https://www.developpez.com
le 25/01/2010 à 13:11
C'est un peu la limite de ce comparatif : il faut très bien connaitre le framework pour pouvoir affirmer qu'il peut ou ne peut pas faire telle chose. Il faudrait en fait que tout le monde puisse contribuer/éditer le tableau pour avoir un véritable comparatif. D'ailleurs tu peux lui faire remarquer si tu as cun compte google, en ajoutant un commentaire

Les "approches" pour moi c'est de l'émotionnel, c'est une question de gout donc je comprends qu'il n'en parle pas :-) Mais c'est vrai que c'est un point que Mockito met beaucoup en avant et que beaucoup de gens aiment. Ceka étant dit, JMockit a aussi beaucoup évolué. Il me semble que l'API Verifications se rapproche de Mockito dans le sens ou les attentes sont vérifiées apres l'appel de la méthode testée.

Concernant le BDD avec JMockit, Rogerio a fait une page : http://jmockit.googlecode.com/svn/tr...edTesting.html (pas encore lu).

++
Foucha.
Avatar de TheNOHDirector TheNOHDirector - Membre du Club https://www.developpez.com
le 25/01/2010 à 15:18
Effectivement les "approches" ça a *une part* d'émotionnel, mon commentaire se voulait pragmatique sur la verbosité ou sur l'expressivité de l'API. Je pense que les différences sont appréciables de manière raisonnées et non émotionnelle, évidement je tergiverse peut-être sur cette limite floue.

Autrement je regardait encore la matrice et avec mockito il est facile de mettre en place des mocks en cascade.

Code : Sélectionner tout
1
2
3
Listener mock = mock(Listener.class, withSettings() 
     .name("firstListner").defaultBehavior(RETURNS_MOCKS)); 
   );
Enfin bref la javadoc est bien faite pour savoir ça
Avatar de foucha foucha - Membre actif https://www.developpez.com
le 25/01/2010 à 16:05
Très intéressant, je ne savais pas que Mockito gérait cela.

Par contre c'est un peu différent non? C'est seulement s'il n'arrive pas à retourner le véritable objet qu'un mock est retourné.

http://mockito.googlecode.com/svn/br...#RETURNS_MOCKS
Avatar de TheNOHDirector TheNOHDirector - Membre du Club https://www.developpez.com
le 25/01/2010 à 16:46
Ce n'est pas tout à fait ça, c'est s'il ne s'agit pas d'un type connu et géré du JDK que mockito retournera un mock.

Petit exemple qui m'a pris 5 min à écrire :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
@Test 
public void mockityoTest() throws Exception { 
	class MyClass { 
		public Integer returnPrimitiveWrapper() { 
			return 400; 
		} 
 
		public int returnPrimitive() { 
			return 400; 
		} 
 
		public String returnString() { 
			return "400"; 
		} 
 
		public Map<Integer, String> returnMap() { 
			return Maps.newHashMap(); 
		} 
 
		public InvocationHandler returnHandler() { 
			return new InvocationHandler() { 
				public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable { 
					return "blah"; 
				} 
			}; 
		} 
	} 
 
	MyClass mockedWithDefaultSettings = mock(MyClass.class); 
	assertEquals(Integer.valueOf(0), mockedWithDefaultSettings.returnPrimitiveWrapper()); 
	assertEquals(0, mockedWithDefaultSettings.returnPrimitive()); 
	assertEquals(null, mockedWithDefaultSettings.returnString()); 
	assertEquals(null, mockedWithDefaultSettings.returnString()); 
	assertEquals(Maps.newHashMap(), mockedWithDefaultSettings.returnMap()); 
	assertNull(mockedWithDefaultSettings.returnHandler()); 
 
	MyClass mockedWithReturningMocksSettings = mock(MyClass.class, withSettings().defaultAnswer(RETURNS_MOCKS)); 
	assertEquals(Integer.valueOf(0), mockedWithReturningMocksSettings.returnPrimitiveWrapper()); 
	assertEquals(0, mockedWithReturningMocksSettings.returnPrimitive()); 
	assertEquals("", mockedWithReturningMocksSettings.returnString()); 
	assertEquals(Maps.newHashMap(), mockedWithReturningMocksSettings.returnMap()); 
	assertThat(mockedWithReturningMocksSettings.returnHandler(), Matchers.instanceOf(InvocationHandler.class)); // ici on aura un mock 
}
Avatar de fredop fredop - Nouveau membre du Club https://www.developpez.com
le 06/04/2011 à 15:46
J'ai testé EasyMock et Mockito. Et Mockito a gagné mon coeur haut la main : en moins de ligne on fait quasi pareil et je trouve l'api plus clair.
Avatar de leminipouce leminipouce - Membre éprouvé https://www.developpez.com
le 28/02/2012 à 11:44
Personnellement j'utilise EasyMock avec Unitils (et donc unitils-easymock).

L'avantage d'unitils est qu'il permet de déclarer tes Mock et leur injecter des attributs via des annotations. Ce n'est pas encore complet, mais ça a d'énormes avantages qui permettent d'écrire très rapidement des TU.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
import static junit.framework.Assert.assertEquals; 
import static junit.framework.Assert.assertFalse; 
import static junit.framework.Assert.assertTrue; 
import static org.easymock.EasyMock.expect; 
import static org.junit.Assert.fail; 
 
import org.junit.Test; 
import org.junit.runner.RunWith; 
import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 
import org.unitils.easymock.EasyMockUnitils; 
import org.unitils.easymock.annotation.Mock; 
import org.unitils.easymock.util.Calls; 
import org.unitils.inject.annotation.InjectIntoByType; 
import org.unitils.inject.annotation.TestedObject; 
 
@RunWith(UnitilsJunit4WithRulesRunner.class) 
public class OrderTestCase { 
    private final static Logger LOGGER = LoggerFactory 
            .getLogger(OrderTestCase.class); 
 
    private static final String FROM_CLAUSE = "FROM CLAUSE"; 
    private static final String PROPERTY_NAME = "PROPERTY NAME"; 
    private static final String ASC = " asc"; 
    private static final String DESC = " desc"; 
 
    @TestedObject 
    OrderTranslatorStrategy orderHQLTranslatorStrategy; 
 
    /** 
     * Qui va permettre de récupérer la {@link TranslatorStrategy} pour 
     * l'expression à traduire. 
     */ 
    @Mock 
    @InjectIntoByType 
    TranslatorStrategyProvider translatorStrategyProvider; 
    @Mock 
    Join join; 
    @Mock(calls = Calls.LENIENT) 
    Order order; 
    @Mock 
    SimpleExpression simpleExpression; 
    @Mock 
    TranslatorContext translatorContext; 
    @Mock(calls = Calls.LENIENT) 
    Query query; 
 
    @Mock 
    TranslatorStrategy translatorStrategy; 
 
    /** 
     * Vérifie qu'on ne peut pas traduire un {@link Join} avec un 
     * {@link OrderTranslatorStrategy}. 
     */ 
    @Test 
    public void testTranslateJoinFail() { 
        assertFalse(orderHQLTranslatorStrategy.canTranslate(join)); 
    } 
 
    /** 
     * Vérifie qu'on peut traduire un {@link Order} avec un 
     * {@link OrderTranslatorStrategy}. 
     */ 
    @Test 
    public void testTranslateOrder() { 
        assertTrue(orderHQLTranslatorStrategy.canTranslate(new Order( 
                PROPERTY_NAME, true))); 
    } 
}
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Java : Mickael Baron - Robin56 -