Section Mocks

La section Mocks est là où vous définissez les réponses simulées que MicroLab sert quand une dépendance est résolue en mock. Elle vous permet de travailler sans VPN et sans lancer le core que votre micro appelle.

Pas besoin de lancer quoi que ce soit pour éditer les mocks : le catalogue vit sur disque (.microlab/mocks/<service>.json) et est servi avec rechargement à chaud, ainsi un changement s’applique instantanément même si le scénario est en cours.

L’arbre : services → endpoints

Le côté affiche un arbre de services (les cores mockables) et, dans chacun, ses endpoints. Les endpoints sont groupés en dossiers repliables dérivés des segments de leur chemin, sans que vous ayez à les organiser à la main.

Un service est mockable s’il est une dépendance d’un micro (ou si vous créez son fichier dans .microlab/mocks). Vous pouvez afficher ou masquer les services qui n’ont pas encore de stubs.

Créer un stub

Appuyez sur Nouveau stub (ou le menu « ⋮ ») et choisissez le service cible —un du catalogue ou un nouveau qui se crée à l’enregistrement—. Un endpoint se définit avec :

Méthode et chemin (relatif au chemin de base du service).
Une ou plusieurs variantes de réponse.

Il y a deux façons de remplir le corps :

Depuis OpenAPI : si le service déclare une spécification OpenAPI (dans le manifeste du micro, ou dérivée de son URL cloud), sélectionnez l’opération et MicroLab génère un modèle du corps.
Manuel : s’il n’y a pas d’OpenAPI, vous écrivez le corps JSON à la main.

Variantes : l’unité de travail

Un endpoint peut avoir plusieurs variantes (par exemple une 200 et une 500). Chaque variante a son étiquette, son code d’état, son corps (JSON), ses en-têtes et une latence optionnelle en millisecondes pour simuler de la lenteur.

La variante sélectionnée s’étend en ligne avec son corps, ses en-têtes et ses réglages ensemble. La variante qui est servie est marquée à part avec un basculement (elle est indépendante de celle que vous éditez) : c’est la réponse que MicroLab renverra à quiconque appelle cet endpoint.

Vous pouvez dupliquer une variante pour partir d’une similaire, et activer ou désactiver un endpoint entier (un désactivé n’est ni servi ni édité).

Enregistrement automatique

L’éditeur de mocks s’enregistre tout seul, avec un léger délai, pendant que vous tapez ; vous verrez un indicateur « Enregistré ». Garde-fous :

Seuls les états valides sont persistés : un corps JSON à moitié écrit ne casse pas le mock servi —le dernier valide est gardé sur disque et l’erreur est marquée en ligne—.
Un stub nouveau n’est pas persisté tant qu’il n’a pas une méthode et un chemin utilisables.
La suppression est toujours explicite, avec confirmation.

Mock Studio : d’un appel réel à un stub

Quand un scénario tourne et qu’un micro appelle un mock qui n’a pas encore de réponse, cet appel apparaît dans le dock Appels mock. De là, vous pouvez créer un stub en un clic à partir de l’appel observé : vous allez droit à l’endpoint que vous voulez compléter, sans le chercher. Vous pouvez aussi tester ce que le mock répondrait sans rien lancer.

Importer et exporter

Avec les icônes d’import/export du panneau :

Exporter les endpoints d’un service (ou de plusieurs) vers un fichier JSON.
Importer votre propre JSON ou une collection Postman (ses dossiers se mappent aux services).

Utile pour partager un catalogue de mocks ou le réutiliser entre scénarios.

La même chose depuis le CLI

Tout cela existe aussi dans le CLI : microlab mock services, mock catalog, mock save, mock set-active, mock skeleton, mock from-call, mock probe, mock import / export. Voir la référence du CLI.