Simuler un service que vous ne contrôlez pas
Le cas est toujours le même : votre flux passe par un service qui n'est pas le vôtre, et vous ne pouvez pas l'atteindre. Vous n'avez pas de VPN aujourd'hui, il est en panne, une autre équipe le maintient, ou il n'existe carrément pas encore. Un mock débloque l'après-midi — et c'est aussi le moyen le plus facile de passer une semaine à tester contre un mensonge.
D'abord : est-ce d'un mock que vous avez besoin ?
La question qui décide n'est pas « puis-je atteindre ce service ? », mais « est-ce que je teste sa réponse ou est-ce que je la traverse ? ».
| Situation | Quoi utiliser | Pourquoi |
|---|---|---|
| Vous avez besoin qu'il renvoie quelque chose pour que votre flux continue | Mock | Son contenu n'est pas ce que vous vérifiez ; c'est une précondition |
| Vous vérifiez comment votre code réagit à ce qu'il renvoie | Le service réel | Un stub vous dira que tout va bien, et vous ne le saurez pas |
| Vous poursuivez un défaut qui n'apparaît que contre le vrai | L'environnement partagé | Le défaut vit dans l'écart entre le stub et l'original |
| C'est un test d'intégration | Testcontainers ou un double dans le test | Le cycle de vie est gouverné par le test, pas par vous |
| Le service n'existe pas encore | Mock depuis son contrat | C'est le cas où le mock ne peut pas mentir : il est la seule source |
Le risque que personne ne raconte : le stub reste immobile
Un mock fige un contrat. Le service réel continue de changer, et votre stub n'en sait rien : de nouveaux champs que vous ne renvoyez pas, un code d'erreur qui signifie désormais autre chose, un format de date qui a changé. Votre code passe en local et échoue à l'intégration, ce qui est exactement le problème que le mock promettait d'éviter.
Deux choses le réduisent beaucoup, et aucune n'est « faire attention » :
- Générez le stub depuis le contrat, pas de mémoire. S'il y a un OpenAPI, le squelette de la réponse en sort et se régénère quand le contrat change.
- Capturez de vrais appels le jour où vous avez accès, et convertissez-les en stubs. Un exemple capturé n'invente rien.
Les quatre façons de le monter
| Façon | Coût d'entrée | Où cela casse |
|---|---|---|
| Un serveur de stubs (WireMock, MockServer) dans votre compose | Un conteneur de plus et ses fichiers de mapping | Il faut quand même y rediriger l'URL de l'appelant, dans la configuration d'un dépôt qui n'est pas le vôtre |
| Un faux service écrit à la main | Une demi-heure, et c'est fait | Cela devient un projet que personne ne maintient et dont personne ne sait à qui il appartient |
| Intercepter dans le client HTTP du service lui-même | Peu, si le framework le permet | C'est du faux code dans votre dépôt, et quelqu'un le commitera |
| Un mock intégré à l'orchestrateur | Installer l'outil | Cela lie l'environnement local à cet outil |
Remarquez que trois des quatre partagent le même point de douleur, et ce n'est pas d'écrire le stub : c'est de faire que l'appelant aille au stub. Cela signifie changer une URL dans la configuration d'un dépôt qui souvent n'est pas le vôtre, et le défaire quand vous voulez revenir au service réel.
Comment Aseptic le fait
Aseptic traite « où appelle cette dépendance » comme une décision de première classe, pas
comme une édition de fichier. Pour chaque dépendance vous choisissez entre trois
destinations —le service local, votre environnement dans le cloud ou un mock— et le
moteur réécrit l'URL au démarrage, en l'injectant comme propriété
-D ou variable d'environnement.
Conséquences pratiques :
- Le dépôt n'est pas touché. Rien à commiter, rien à annuler, rien à relire dans une pull request.
- Revenir en arrière, c'est changer la destination, pas défaire une édition. Vous pouvez faire des allers-retours entre mock et service réel plusieurs fois dans un après-midi.
- Le reste du scénario s'en aperçoit tout seul : la décision est prise une fois et tous ceux qui appellent ce service l'appliquent.
Les stubs se définissent dans le Mock Studio : capturer un appel et le convertir en stub d'un clic, générer le squelette de la réponse depuis un OpenAPI, et organiser des variantes par service —la réponse heureuse, celle qui renvoie 404, celle qui traîne— avec rechargement à chaud, sans rien redémarrer.
Ce qu'un mock ne vous donnera pas
Il faut le dire ici, parce que c'est là qu'on perd du temps : si le défaut que vous poursuivez vit dans le service réel —un en-tête que la passerelle ajoute, un payload que personne n'a documenté, le comportement sous charge— le mock ne le reproduira pas, par définition. Ce qu'il faut alors, c'est atteindre l'environnement partagé, et si votre système est trop grand pour votre machine, le comparatif avec Telepresence explique l'autre approche.
Les étapes concrètes sont dans simuler une dépendance, et si ce qui vous bloque est qu'il faut démarrer trop de choses, la page sur démarrer seulement une partie du système.
Questions fréquentes
Quand faut-il simuler un service et quand non ?
Simulez-le quand sa réponse n'est pas ce que vous testez : vous en avez besoin pour que votre flux avance, pas pour la vérifier. Ne le simulez pas quand ce que vous voulez vérifier est précisément la façon dont votre code réagit à ce que ce service renvoie réellement —là, un stub vous dira que tout va bien et ce ne sera pas vrai—.
Un mock ne va-t-il pas finir par me mentir ?
Il le peut, et c'est son vrai risque : le stub fige un contrat qui continue de changer de l'autre côté. On l'atténue en le générant depuis l'OpenAPI du service plutôt qu'à la main, et en capturant de vrais appels quand vous pouvez l'atteindre.
Comment basculer entre le service réel et le mock sans éditer mes dépôts ?
Avec Aseptic c'est une décision par dépendance : vous choisissez local, cloud ou mock et l'URL est réécrite au démarrage, injectée comme configuration. Le fichier du dépôt reste exactement tel qu'il est dans git.
Dois-je écrire le stub à la main ?
Pas nécessairement. On peut générer le squelette de la réponse depuis un OpenAPI, ou capturer un appel réel la seule fois où vous aviez accès et le convertir en stub d'un clic.