Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 17 sur 17
  1. #1
    Futur Membre du Club
    Inscrit en
    septembre 2007
    Messages
    40
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 40
    Points : 19
    Points
    19

    Par défaut 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 .

  2. #2
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 674
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 674
    Points : 7 851
    Points
    7 851

    Par défaut

    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

  3. #3
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 382
    Points
    1 382

    Par défaut

    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.

  4. #4
    Invité régulier
    Inscrit en
    octobre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : octobre 2008
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    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 .

  5. #5
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    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.

  6. #6
    Invité régulier
    Inscrit en
    octobre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : octobre 2008
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    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.

  7. #7
    Membre Expert

    Homme Profil pro Michel Dirix
    Doctorant
    Inscrit en
    juin 2009
    Messages
    775
    Détails du profil
    Informations personnelles :
    Nom : Homme Michel Dirix
    Âge : 27
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2009
    Messages : 775
    Points : 1 020
    Points
    1 020

    Par défaut

    Pour ma part j'utilise Mockito que je trouve très simple d'utilisation et de compréhension!

  8. #8
    Futur Membre du Club
    Inscrit en
    août 2009
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : août 2009
    Messages : 39
    Points : 15
    Points
    15

    Par défaut

    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 !

  9. #9
    Membre confirmé
    Avatar de foucha
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2009
    Messages : 121
    Points : 238
    Points
    238

    Par défaut

    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.

  10. #10
    Membre confirmé
    Avatar de foucha
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2009
    Messages : 121
    Points : 238
    Points
    238

    Par défaut 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.
    ++
    Foucha.

    =========

    "du code propre c'est du code qui fait exactement ce qu'on croit que ça fait"

    Mes Articles DVP

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    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.

  12. #12
    Membre confirmé
    Avatar de foucha
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2009
    Messages : 121
    Points : 238
    Points
    238

    Par défaut

    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.
    ++
    Foucha.

    =========

    "du code propre c'est du code qui fait exactement ce qu'on croit que ça fait"

    Mes Articles DVP

  13. #13
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    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

  14. #14
    Membre confirmé
    Avatar de foucha
    Profil pro
    Inscrit en
    janvier 2009
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2009
    Messages : 121
    Points : 238
    Points
    238

    Par défaut

    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
    ++
    Foucha.

    =========

    "du code propre c'est du code qui fait exactement ce qu'on croit que ça fait"

    Mes Articles DVP

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    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
    }

  16. #16
    Futur Membre du Club
    Inscrit en
    mars 2009
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : mars 2009
    Messages : 23
    Points : 15
    Points
    15

    Par défaut

    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.

  17. #17
    Membre Expert Avatar de leminipouce
    Homme Profil pro Olivier
    Ingénieur développement logiciels
    Inscrit en
    janvier 2004
    Messages
    754
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : janvier 2004
    Messages : 754
    Points : 1 149
    Points
    1 149

    Par défaut

    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)));
        }
    }
    Si , et la ont échoué mais pas nous, pensez à dire et cliquez sur . Merci !

    Ici, c'est un forum, pas une foire. Il y a de respectables règles... à respecter !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •