FAQ Tests Consultez toutes les FAQ
Nombre d'auteurs : 2, nombre de questions : 40, dernière mise à jour : 31 décembre 2017 Ajouter une question
Cette FAQ a été réalisée à partir des questions fréquemment posées sur les forums de http://www.developpez.com et de l'expérience personnelle des auteurs.
Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.
- 3.1. Le framework Mockito (8)
Bien que les concepts d'objets simulacres (mocks) et de bouchons (stubs) soient proches, on peut noter les différences suivantes :
Les bouchons (stubs) sont basés sur une vérification d'état. Ils permettent de s'abstraire d'une dépendance en fournissant des méthodes, Web services, base de données, ayant les mêmes entrants que cette dépendance, mais en fournissant une réponse contrôlée ou prédéfinie.
Ainsi l'utilisation de bouchons permet de :
- tester uniquement la méthode que l'on souhaite tester sans dépendre du résultat fourni par la dépendance en question ;
- de développer autour de dépendances non implémentées.
Les objets simulacres (mocks), eux, sont basés sur une vérification de comportement. Contrairement aux bouchons, il ne peut s'agir que d'objets, mais dont le comportement est également totalement contrôlé. Contrairement aux bouchons qui sont appelés de manière transparente pour l'appelant, l'utilisation de mocks repose sur l'injection de dépendances.
Le gros avantage des mocks par rapport aux simples bouchons : permet d'être mis en place très rapidement à l'aide d'API comme Mockito au sein même d'un testCase JUnit et permet de faire des assertions sur les appels aux méthodes du mock (vérifier qu'on appelle bien telle méthode avec tels arguments par exemple).
Les mocks sont donc plus adaptés à l'écriture de tests unitaires ou l'on ne charge que la classe à tester en essayant de passer par tous les chemins possibles et de faire le maximum d'assertions sur les cas de tests possibles.
Les bouchons, quant à eux, sont davantage adaptés à la mise en place de tests d'intégration où l'on charge une partie de l'environnement des portions de code testées (par exemple : de vrais appels HTTP à des Web services bouchonnés dans le cadre d'un projet SOA).
Qu'est-ce que l'injection de dépendances ?
L'injection de dépendances est un principe de programmation orientée objet qui consiste à découpler les dépendances entre objets en injectant dynamiquement les instances de ces dépendances dans les classes manipulant ces dépendances (en passant par des métadonnées par exemple). Le framework Java par excellence qui implémente ce principe est sans nul doute le framework Spring qui rattache les beans les uns aux autres en passant par des fichiers XML.
Concrètement, l'injection de dépendances préconise que chaque dépendance ne soit plus directement instanciée par les classes manipulant ces dépendances. Voici un exemple en code qui permet de mieux comprendre le principe :
Code Java : | 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 | // Ne permet pas l'injection de dépendances entre ClasseA et ClasseB public ClasseA { private ClasseB objetDependance = new ClasseB(...); } // Ne permet pas non plus l'injection de dépendances entre ClasseA et ClasseB public ClasseA { private ClasseB objetDependance; public ClasseA (){ objetDependance = new ClasseB(...); } } // Permet l'injection de dépendances entre ClasseA et ClasseB à l'aide d'une classe intermédiaire ou encore de métadonnées public ClasseA { private IInterfaceClasseB objetDependance; public void setObjetDependance(IInterfaceClasseB objetDependance){ this.objetDependance = objetDependance; } public ClasseB getObjetDependance(IInterfaceClasseB objetDependance){ return objetDependance; } } |
L'injection de dépendances permet, entre autres, de changer les implémentations des objets injectés en passant par des interfaces, mais aussi d'injecter des objets simulacres en lieu et place de ces dépendances.
Il n'est pas toujours aussi simple de revoir tout un projet pour y faire de l'injection de dépendances en passant par des métadonnées ni de mettre en place Spring sur une architecture déjà prédéfinie et fixée. Dans ce cas, il existe une technique simple pour remplacer l'injection de dépendances afin de faciliter vos tests unitaires :
Code Java : | 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 | public ClasseA { private IInterfaceClasseB objetDependance; public void setObjetDependance(IInterfaceClasseB objetDependance){ this.objetDependance = objetDependance; } // instance par défaut // à ne surtout pas appeler dans un constructeur private void initClassBDefaultDependance(){ // ce test permettra de laisser la possibilité d'injecter une autre instance de ClasseB via le setter if (null == objetDependance){ objetDependance = new ClasseB(...); // autres opérations pour valoriser l'instance de objetDependance } } public IInterfaceClasseB getObjetDependance(IInterfaceClasseB objetDependance){ initClassBDefaultDependance(); return objetDependance; } } |
Ainsi, dans vos tests, il vous sera tout aussi possible d'injecter un mock de ClasseB en passant par le setter tandis que l'application, elle, utilisera l'instance par défaut de la méthode initClassBDefaultDependance de manière totalement transparente.
Voici une liste non exhaustive des frameworks permettant de mettre en place des objets simulacres en Java :
Mockito est sans doute le plus populaire à l'heure actuelle.
Proposer une nouvelle réponse sur la FAQ
Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour çaLes sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2024 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.