API Mock, laquelle choisir ?

Version imprimable

06/10/2009, 13h41
Khrono

API Mock, laquelle choisir ?

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 :).
06/10/2009, 15h57
djo.mos

Salut,
La plupart (pour ne pas dire toutes) des bibliothèques de mocking sont fonctionnellement équivalentes. Donc, le choix va se baser sur d'autres critères, comme la documentation (commes tu le dis) ou le style.

Perso, j'ai opté pour Mockito car j'aime bien comment ça s'utilise; son API.

Pour quelques comparatifs, tu peux regarder Mockito vs EasyMock et encore Mockito vs RMock
07/10/2009, 10h42
dingoth

Je n'ai jamais utilisé que EasyMock et JMock.

Techniquement parlant, je trouve les deux API satisfaisantes selon mes besoins, et n'ai aucune plainte à faire à aucun des deux projets.

En terme d'usabilité, je trouve JMock plus facile à apprendre/utiliser, mais c'est subjectif.

Par contre, je n'aime pas du tout le genre de comparatifs, montrés par Djomos, faits par les développeurs d'une API pour montrer que leur API est meilleure. Je préfère prendre des comparatifs indépendants.
07/10/2009, 11h16
sylez

Les fonctionnalités des framework de doublures de tests peuvent varier.

Dans le cas de tests, les doublures de tests permettent de découpler le système tester de son environnement.

Les doublures basiques:
- Comportement Dummy (Le comportement n'est pas testé la doublure est nécessaire; pour EasyMock createNiceMock)
- Comportement Stub/Bouchon (On ne vérifie pas les interractions, seules les réponses)
- Comportement Spy/Espion (Les interractions sont enregistrées et vérifiées aprés coup)
- Comprotement Mock/Simulacre (Les interractions sont attendues lors de l'éxécution)
- Comportement Fake/Implémentation Légère (La on tape dans les tests d'intégrations)

Dans le cas d'un projet Legacy, il faut vite s'orienter sur les mocks partiels (fonctionnalité générique), la surcharge des fonctions statiques, l'injection de mock via le classloader, le mockage des fonctions privés (court-circuit), le mockage avec espions ... ou plus radicalement abandonné les tests unitaires pous s'orienter vers des tests boîtes noires.

Pour un projet ou une évolution from scratch, les fonctinnalités utilisées sont génériques.
Donc choix selon l'API (annotation ou pas, séparation des comportements stub/mock), la doc et la version de Java nécessaire.

A noter que certains projets (Spring par exemples) fournissent leurs bouchons/espions/dummy .
07/10/2009, 11h36
TheNOHDirector

Mockito est vraiment bien pour la plupart des cas de mock énoncés par Sylez.

Pour info au départ c'était un fork de easymock, et maintenant leur code est complètement réécrit. Leur API est nettement plus sympa que celle d'Easymock.
Et pour le coup je trouve le framework plus complet que Easymock seul.
Par contre tu ne pourras pas faire de mock de classes / fonctions statiques, Mockito ne génère que des instances de mock. Et d'ailleurs il est reconnu que les classes / fonctions statiques ne sont pas idéales pour la testabilité.

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.

Si tu veux tester des DAO et que tu fais donc des tests avec une base de donnée, etc, tu peux utiliser DBunit. D'ailleurs si ta base n'utilise pas de features spécifiques au vendeur, eh bien tu pourrais te permettre de faire des tests sur une base hsqldb, ça oblige celà dit d'avoir un schéma synchronisé entre la base sur une machine et la base hsqldb.

unitils intègre pas mal d'outils de test et simplifie l'utilisation de certains framework, il est particulièrement pratique pour son support DBUnit.
08/10/2009, 09h16
sylez

En effet, si le code est propre, EasyMock ou Mockito (je n'ai pas utiliser d'autres framework) suffisent.

Aprés j'ai tendance à dire qu'il faut prendre celui qui vous met le plus à l'aise.

Au pire, le passage de EasyMock vers Mockito ou vice versa est trés simple.

A noter: Il existe une extension pour EasyMock et Mockito , PowerMock, qui permet de couvrir du code crade.
08/10/2009, 09h22
michel.di

Pour ma part j'utilise Mockito que je trouve très simple d'utilisation et de compréhension! :)
08/10/2009, 11h47
asouquieres

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 !
14/10/2009, 16h58
foucha

Citation:

Envoyé par TheNOHDirector

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.
25/01/2010, 11h48
foucha

comparatif

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.
25/01/2010, 12h55
TheNOHDirector

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.
25/01/2010, 13h11
foucha

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 :D

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.
25/01/2010, 15h18
TheNOHDirector
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:

1 2 3 Listener mock = mock(Listener.class, withSettings() .name("firstListner").defaultBehavior(RETURNS_MOCKS)); );
Enfin bref la javadoc est bien faite pour savoir ça :)
25/01/2010, 16h05
foucha

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

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:

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
}

06/04/2011, 15h46
fredop

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.

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:

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)));
    }
}