Mocks section

The Mocks section is where you define the simulated responses MicroLab serves when a dependency is resolved as mock. It lets you work without VPN and without launching the core your micro calls.

You don’t need to start anything to edit mocks: the catalog lives on disk (.microlab/mocks/<service>.json) and is served with hot reload, so a change is applied instantly even if the scenario is running.

The tree: services → endpoints

The side shows a tree of services (the mockable cores) and, within each one, its endpoints. Endpoints are grouped into collapsible folders derived from the segments of their path, without you having to organize them by hand.

A service is mockable if it is a dependency of some micro (or if you create its file in .microlab/mocks). You can show or hide the services that don’t have stubs yet.

Create a stub

Press New stub (or the ”⋮” menu) and choose the target service —one from the catalog or a new one that is created on save—. An endpoint is defined with:

Method and path (relative to the service’s base path).
One or more response variants.

There are two ways to fill the body:

From OpenAPI: if the service declares an OpenAPI specification (in the micro’s manifest, or derived from its cloud URL), select the operation and MicroLab generates a template of the body.
Manual: if there is no OpenAPI, you write the JSON body by hand.

Variants: the unit of work

An endpoint can have several variants (for example a 200 and a 500). Each variant has its label, status code, body (JSON), headers and an optional latency in milliseconds to simulate slowness.

The selected variant expands inline with its body, headers and settings together. The variant that is served is marked separately with a toggle (it’s independent of the one you’re editing): it’s the response MicroLab will return to whoever calls that endpoint.

You can duplicate a variant to start from a similar one, and enable or disable a whole endpoint (a disabled one is neither served nor edited).

Automatic saving

The mock editor saves on its own, with a small delay, while you type; you’ll see a “Saved” indicator. Safeguards:

Only valid states are persisted: a half-written JSON body does not break the served mock —the last valid one is kept on disk and the error is marked inline—.
A new stub is not persisted until it has a usable method and path.
Deletion is always explicit, with confirmation.

Mock Studio: from a real call to a stub

When a scenario runs and a micro calls a mock that doesn’t have a response yet, that call appears in the Mock calls dock. From there you can create a stub with one click from the observed call: you go straight to the endpoint you want to complete, without searching for it. You can also test what the mock would respond without launching anything.

Import and export

With the panel’s import/export icons:

Export a service’s endpoints (or several) to a JSON file.
Import your own JSON or a Postman collection (its folders map to services).

Useful to share a mock catalog or reuse it across scenarios.

The same from the CLI

All of this also exists in the CLI: microlab mock services, mock catalog, mock save, mock set-active, mock skeleton, mock from-call, mock probe, mock import / export. See the CLI reference.