Votre code dépend d'un service que vous ne contrôlez pas. Une passerelle de paiement, une API partenaire, un système central hérité, le microservice d'une autre équipe. Cette dépendance est en maintenance, limite le nombre de vos exécutions de tests, facture par appel ou renvoie des données instables. Votre développement est alors bloqué et votre pipeline CI passe au rouge pour des raisons qui n'ont rien à voir avec votre code.
La virtualisation de services résout ce problème. Vous remplacez la dépendance réelle par un substitut qui se comporte comme elle, afin de pouvoir développer et tester avec quelque chose que vous maîtrisez entièrement. Ce guide explique ce qu'est la virtualisation de services, comment elle diffère du mocking et du stubbing, pourquoi les équipes l'utilisent, et quels outils sont adaptés, avec des commandes réelles pour WireMock, Hoverfly, Mountebank, les options d'entreprise et le serveur de mock d'Apidog pour la virtualisation de contrats d'API.
Qu'est-ce que la virtualisation de services
La virtualisation de services simule le comportement d'une dépendance que vous ne contrôlez pas, afin que votre application puisse communiquer avec la simulation plutôt qu'avec l'objet réel.
Le mot « comportement » est important ici. Un bon service virtuel ne se contente pas de renvoyer une charge utile fixe. Il correspond aux détails de la requête, renvoie des réponses différentes pour des entrées différentes, maintient un état entre les appels, injecte de la latence et des erreurs, et utilise le même protocole que le système réel. L'objectif est un substitut suffisamment réaliste pour que votre code ne puisse pas faire la différence pendant le développement et les tests.
Le terme « virtualisation d'API » signifie la même chose lorsque la dépendance est une API HTTP, et « simulateur d'API » est l'outil qui produit le point de terminaison virtuel. Traitez les deux comme des synonymes de la part de la virtualisation de services axée sur les API.
Virtualisation de services vs mocking vs stubbing
Ces trois termes se chevauchent et sont souvent utilisés de manière lâche. Voici une manière pratique de les distinguer.
Un stub renvoie une réponse codée en dur. Il ignore la requête et répond toujours de la même manière. Si votre test appelle GET /user/42 et que le stub est configuré pour renvoyer un objet utilisateur fixe, il renvoie ce même objet quel que soit l'ID que vous envoyez. Les stubs sont la forme la plus simple et résident dans votre code de test.
Un mock est un stub qui vérifie également les interactions. Il enregistre la manière dont il a été appelé (quelles méthodes, quels arguments, combien de fois) afin que votre test puisse vérifier que votre code a utilisé la dépendance correctement. Les mocks sont un outil de test unitaire. Ils s'exécutent généralement en cours de processus, dans le même langage que votre code. Notre explication sur le stubbing d'API vs mocking d'API approfondit cette distinction.
La virtualisation de services opère sur le réseau, pas dans votre code. Elle met en place un service en cours d'exécution sur un port réseau réel qui utilise un protocole réel. Votre application s'y connecte de la même manière qu'elle se connecterait à la production, en modifiant une URL de base ou un paramètre de proxy. Un service virtuel peut être étatique, peut correspondre à des conditions de requête complexes et peut simuler un comportement au niveau du protocole comme les codes d'état HTTP, les en-têtes, le streaming et les erreurs de connexion.
La frontière entre « mock » et « virtualisation de services » est floue dans le langage courant. De nombreuses équipes appellent un serveur de mock HTTP en cours d'exécution « un mock » même s'il réalise une virtualisation complète. C'est normal. La distinction qui compte : remplacez-vous un objet au sein de votre processus (mocking/stubbing) ou mettez-vous en place un service en réseau auquel votre application se connecte (virtualisation) ? Voir API mocking : tout ce que vous devez savoir pour le côté mock.
Pourquoi les équipes utilisent la virtualisation de services
Trois problèmes motivent la plupart des adoptions.
La dépendance n'est pas prête. Les équipes frontend et backend travaillent en parallèle, et le frontend a besoin d'une API fonctionnelle avant que le backend ne la livre. Un service virtuel construit à partir du contrat d'API permet au frontend de travailler avec des réponses réalistes dès aujourd'hui. Personne n'attend.
La dépendance est coûteuse ou soumise à des limites de taux. Les API tierces facturent souvent par appel ou limitent agressivement, de sorte que l'exécution d'une suite de tests complète sur un environnement de test réel consomme du quota et de l'argent. Un service virtuel peut être appelé gratuitement, ce qui permet à votre CI d'exécuter des milliers de scénarios par jour.
La dépendance est instable ou difficile à contrôler. Vous ne pouvez pas facilement forcer un fournisseur de paiement réel à renvoyer une erreur spécifique, à expirer ou à envoyer une réponse mal formée. Un service virtuel produit n'importe laquelle de ces situations à la demande, ce qui vous permet de tester les chemins d'erreur qui se manifestent en production.
Il y a aussi un avantage en termes de contrôle. Les dépendances réelles ont des données qui changent sous vos yeux. Un service virtuel vous donne un état fixe et connu, de sorte que vos tests sont déterministes. Une build verte signifie que votre code fonctionne, pas qu'un système distant s'est comporté correctement aujourd'hui.
Comment fonctionne la virtualisation de services
La plupart des outils suivent l'un des deux modèles.
Enregistrement et relecture. Vous pointez l'outil vers le service réel comme un proxy, vous y faites passer un trafic réel une fois, et il capture les paires requête/réponse. Plus tard, il rejoue ces enregistrements au lieu d'appeler le service réel. C'est rapide car vous n'écrivez pas les réponses manuellement. Le mode de capture de Hoverfly et le mode d'enregistrement de WireMock fonctionnent tous deux de cette manière.
Basé sur les spécifications. Vous définissez le service virtuel à partir d'un contrat d'API ou manuellement : déclarez quelles requêtes correspondent à quelles réponses, ajoutez des valeurs dynamiques et configurez un comportement étatique. C'est plus de travail au départ, mais cela vous donne un contrôle total et fonctionne même lorsque le service réel n'existe pas encore.
Dans les deux cas, le mécanisme principal est la correspondance des requêtes. Lorsqu'une requête arrive, l'outil la compare à un ensemble de règles (chemin, méthode, paramètres de requête, en-têtes, corps) et renvoie la réponse liée à la première correspondance. Les meilleurs outils ajoutent le templating, de sorte qu'une réponse peut renvoyer des parties de la requête ou générer de nouvelles valeurs à chaque appel. C'est ainsi qu'un service virtuel semble vivant au lieu d'être statique.
Les outils
Voici les principales options, des outils open-source axés sur HTTP aux suites d'entreprise lourdes. Vérifiez les versions et fonctionnalités actuelles par rapport à la documentation de chaque projet avant de vous engager, car ceux-ci évoluent rapidement.
WireMock
WireMock est un outil open-source de mocking d'API et de virtualisation de services pour HTTP. Il s'exécute en tant que processus autonome, intégré dans des tests JVM ou dans un conteneur. Vous définissez les mappages de stubs en JSON, et WireMock compare les requêtes entrantes avec ceux-ci. Il prend en charge l'enregistrement et la relecture par rapport à un service réel, le templating de réponses, les scénarios étatiques, l'injection de fautes et les délais simulés.
Exécutez le JAR autonome :
java -jar wiremock-standalone-3.13.2.jar --port 8080
Ensuite, enregistrez un stub via son API d'administration :
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock est le plus efficace lorsque vos dépendances sont HTTP et que vous souhaitez un contrôle précis dans des configurations JVM ou conteneurisées. Il existe une version commerciale hébergée (WireMock Cloud) si vous souhaitez une option gérée.
Hoverfly
Hoverfly est un outil de virtualisation de services open-source léger, écrit en Go. Il fonctionne comme un proxy : vous routez le trafic sortant de votre application via Hoverfly, et il enregistre les réponses réelles ou rejoue des réponses simulées. Il s'exécute dans plusieurs modes, notamment capture, simulate, spy, modify, synthesize et diff.
Un flux de capture-puis-relecture de base utilisant sa commande hoverctl :
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
L'API d'administration de Hoverfly s'exécute sur le port 8888 et son proxy sur le port 8500 par défaut. Le modèle de proxy d'enregistrement et de relecture le rend adapté lorsque vous souhaitez virtualiser rapidement un trafic existant plutôt que d'écrire manuellement chaque réponse. Il existe également un Hoverfly Cloud hébergé.
Mountebank
Mountebank est un outil open-source construit autour des « imposteurs ». Un imposteur est un service virtuel unique qui écoute sur un port et utilise un protocole. Au-delà de HTTP et HTTPS, Mountebank gère également TCP et SMTP, ce qui est utile lorsque votre dépendance n'est pas une simple API REST. Vous le contrôlez entièrement via un plan de contrôle REST sur le port 2525.
Installez-le et démarrez-le :
npm install -g mountebank
mb
Ensuite, créez un imposteur en envoyant du JSON au port de contrôle :
curl -X POST http://localhost:2525/imposters \
-H "Content-Type: application/json" \
-d '{
"port": 4545,
"protocol": "http",
"stubs": [{
"predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
"responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Les prédicats décident quelle requête correspond ; les réponses définissent ce qui est renvoyé. La capacité multi-protocole de Mountebank est son facteur de différenciation parmi les options open-source.
Parasoft Virtualize et Broadcom Service Virtualization
Pour les grandes entreprises, les poids lourds sont Parasoft Virtualize et Broadcom Service Virtualization (faisant partie de la suite DevTest). Ce sont des plateformes commerciales conçues pour les équipes qui doivent simuler de nombreux protocoles et formats de messages au-delà de HTTP, connecter des services virtuels à des sources de données réelles et gérer la virtualisation dans de nombreux environnements de manière centralisée.
Parasoft Virtualize annonce un support pour une large gamme de protocoles et de formats de messages standards de l'industrie, ainsi que des services virtuels basés sur des données alimentés par des sources de données externes. L'offre de Broadcom vise des scénarios d'entreprise similaires avec des environnements virtualisés pour le développement et les tests parallèles. Les deux impliquent des licences d'entreprise et des frais d'installation, ils conviennent donc lorsque vous virtualisez des protocoles hérités (mainframe, MQ, messages à longueur fixe) à grande échelle plutôt qu'une poignée de points de terminaison REST. Si vos dépendances sont des API HTTP ordinaires, les outils open-source mentionnés ci-dessus ou une plateforme API vous couvrent à une fraction du coût. Confirmez les listes de protocoles actuels et les tarifs auprès de chaque fournisseur.
Apidog : virtualisation de services légère pour les contrats d'API
Si la dépendance que vous devez virtualiser est une API HTTP définie par un contrat, Apidog couvre cette partie sans outil séparé. Lorsque vous concevez ou importez une API, Apidog met automatiquement en place un serveur de mock pour celle-ci. Votre frontend ou votre suite de tests obtient un point de terminaison fonctionnel à partir du schéma seul, avant même que tout code backend n'existe.
Ce qui le rend plus proche de la virtualisation qu'un simple stub, c'est que le mock d'Apidog est conscient du schéma et dynamique. Son Smart Mock lit votre schéma JSON et génère des réponses qui respectent toutes les contraintes (types, formats, énumérations, champs obligatoires). Il fait également correspondre les noms de champs à des règles intégrées, de sorte qu'un champ nommé `email` renvoie une adresse e-mail valide et un champ nommé `city` renvoie un nom de ville, au lieu de données de remplissage inutiles. Pour un contrôle plus fin, des valeurs dynamiques basées sur Faker.js génèrent des données réalistes à chaque appel, et vous pouvez fixer des valeurs là où vous avez besoin de déterminisme.
Vous pouvez également écrire des règles de mock personnalisées qui renvoient des réponses différentes en fonction des paramètres de la requête, ce qui est le comportement de correspondance de requête qui sépare la virtualisation d'un stub fixe. Le serveur de mock s'exécute dans l'interface graphique ou en mode headless, il convient donc au développement local et à l'intégration continue (CI). Voir comment mocker une API en une minute pour un guide détaillé.
Où Apidog convient : virtualisation de services basée sur les contrats d'API pour HTTP/REST et similaires. Où il ne convient pas : ce n'est pas un outil d'enregistrement et de relecture basé sur proxy pour des protocoles hérités arbitraires, et ce n'est pas un générateur de charge. Pour ceux-là, les outils ci-dessus sont le bon choix. Pour une comparaison plus large des outils, consultez comparaison des outils de mocking d'API en ligne et les 10 meilleurs outils de mocking d'API.
Comment démarrer
Adaptez l'outil à la dépendance, et non l'inverse.
- Identifiez le protocole. HTTP/REST simple ? Presque tout ici fonctionne, et une plateforme API est la solution la moins frictionnelle. Besoin de TCP ou SMTP ? Mountebank. Protocoles d'entreprise hérités à grande échelle ? Parasoft ou Broadcom.
- Décidez entre enregistrement et spécification. Si le service réel existe et que vous pouvez y acheminer du trafic, l'enregistrement et la relecture (Hoverfly, mode d'enregistrement WireMock) sont les plus rapides. S'il n'existe pas encore, pilotez le service virtuel à partir du contrat d'API (Apidog, stubs WireMock, imposters Mountebank).
- Dirigez votre application vers lui. Modifiez une URL de base ou un paramètre de proxy dans votre environnement de test ou de développement, et gardez cela configurable afin que le passage du virtuel au réel soit une seule variable.
- Ajoutez les cas d'échec. L'avantage est de tester les chemins d'erreur, alors ajoutez des réponses pour les 4xx et 5xx, les délais d'attente et les corps mal formés. C'est la partie que les dépendances réelles ne vous permettront pas de répéter.
- Exécutez-le en CI. Un service virtuel qui ne fonctionne que sur votre ordinateur portable vous aide, mais pas la build. Intégrez-le au pipeline pour que vert signifie vert. Si vous avez besoin d'un mock qui s'exécute en mode headless en CI sans interface graphique, consultez les outils de mock d'API headless.
Pour le compromis entre dépendances virtuelles et réelles en général, serveur de mock vs serveur réel explique quand utiliser chacun.
FAQ
La virtualisation de services est-elle la même chose que le mocking ? Pas tout à fait. Le mocking remplace généralement un objet au sein de votre processus pour les tests unitaires et vérifie comment il a été appelé. La virtualisation de services met en place un service en cours d'exécution sur un port réseau auquel votre application se connecte via un protocole réel. Les gens appellent les services virtuels HTTP des « mocks » dans l'usage courant, ce qui est normal, mais la distinction technique est entre un objet en cours de processus et un service en réseau.
Quand devrais-je utiliser un service virtuel au lieu d'un environnement de test réel ? Utilisez la virtualisation lorsque la dépendance réelle est indisponible, soumise à des limites de taux, coûteuse ou difficile à contrôler. Elle vous offre des réponses déterministes, gratuites et toujours disponibles, et vous permet de simuler des erreurs que vous ne pouvez pas déclencher sur le système réel. Conservez un ensemble plus restreint de tests contre le service réel pour une confiance finale dans l'intégration.
Un service virtuel peut-il être étatique ? Oui. Des outils comme WireMock et Mountebank prennent en charge des scénarios étatiques où la réponse change en fonction des requêtes précédentes, par exemple en renvoyant un panier vide, puis un panier avec des articles après un POST. Cela est important lorsque vous simulez des flux de travail plutôt que des appels uniques.
Ai-je besoin d'un outil d'entreprise payant ? Seulement si vous virtualisez de nombreux protocoles non-HTTP ou si vous gérez la virtualisation au sein d'une grande organisation. Pour les API HTTP ordinaires, les outils open-source (WireMock, Hoverfly, Mountebank) ou un serveur de mock de plateforme API font le travail sans licence d'entreprise.
Quel est le moyen le plus rapide de virtualiser une API HTTP à partir de sa spécification ? Importez la définition de l'API dans un outil qui génère un mock à partir du schéma. Apidog le fait automatiquement : importez votre spécification OpenAPI et vous obtenez un serveur de mock conscient du schéma avec des données dynamiques réalistes, sans avoir besoin d'écrire de réponse. De là, vous ajoutez des règles personnalisées pour les conditions de requête/réponse spécifiques dont vos tests ont besoin.