Mocking en Java
L'approche du Mocking
Dans quels cas utiliser un objet de type Mock ?
Voici quelques cas courant dans lesquels se prête l'utilisation d'un objet Mock :
- Simulation d'objets non implémentés
- Simulation de l'appel à ressources (base de données, fichiers, services)
- Simulation de composants à résultats variables
- Simulation de cas d'erreurs
Dans quels cas ne pas utiliser un objet de type Mock ?
- Dans les tests d'intégration
- Dans les dépendances non immédiates
Les tests d'intégration ont pour but de tester le fonctionnement de plusieurs modules de l'application, on teste les intéractions, il n'est donc pas question de réaliser des tests d'intégration avec un Mock qui n'est pas un objet réel. Remarque supplémentaire, les Mock sont destinés à tester les dépendances immédiates et non pas les dépendances d'objets trop éloignées.
Cas d'utilisation possible dans les tests d'intégrations
Voici les seuls cas où l'utilisation d'un objet Mock est possible :
- Module dont le temps de traitement est long
- Module complexe à initialiser
- Simulation de cas d'erreurs
1 responsabilité = 1 classe
Le principe est de limiter les responsabilités d'un objet pour faciliter sa réutilisation. Cela implique qu'un objet a souvent besoin d'autres objets pour réaliser ses tâches. Ces objets dépendants ont eux aussi des dépendances vers d'autres objets. Ces dépendances forment rapidement un graphe d'objets complexe.
On a rapidement des problèmes pour les tests et surtout cela empêche l'isolation du test de l'objet à tester.
1 code mal conçu = pas de mocking
La conclusion est qu'un code mal conçu ne peut pas être utiliser avec du mock. Une architecture mal pensée ne peut pas être testable du point de vue des tests unitaires et donc du point de vue du mock.
L'utilisation d'objets de type mock encourage voir impose l'utilisation d'une conception adaptée du code qui le rend testable, compréhensible et plus maintenable.
- Le code d'une méthode ne doit pas être trop important
- Le code ne doit pas être complexe
- Le code ne doit pas avoir trop de dépendances
- Les dépendances doivent pouvoir être injectées
Il faut maîtriser les dépendances de ses objets => injection de dépendances ( Dependency Injection)
Exemple d'injection de dépendance appelée injection de dépendance par méthode
Dans cet exemple, le traitement de la méthode "maMethode" est fortement dépendant de la classe "MaClasseB". Il y a un problème de conception, ce code ne pourra pas être testable.
En injectant la classe "MaClasseB" dans le constructeur, la méthode "maMethode" pourra être testable et nous pourrons lui fournir un objet de type Mock.
Pour en apprendre plus sur le sujet, renseigner vous sur l'injection de dépendance et l'inversion de contrôle.