Testing with mocks

A mock server answers like the real API, with responses you design. It lets you work when the real API is missing, unstable, expensive, or unwilling to fail on demand. This page covers when a mock is the right tool, how to build a trustworthy one with Mock Studio, and what a mock can never prove.

When to reach for a mock

Situation	What the mock gives you
The API is not built yet	The front end and the tests can start now
The API is someone else's	No dependence on their uptime, rate limits or bills
You need an error on demand	A 500, a timeout or a broken body whenever you ask
The real thing has side effects	No real emails, payments or orders
You need the same answer every time	Stable data, so tests do not flicker
You are teaching or learning	A safe API on your own machine

Two different jobs

Be clear which one you are doing, because they prove different things.

1. Testing a client against a mock. Your app, script or integration is the thing under test. The mock plays the server. This is the main use: does the app show the list, handle the 401, survive the timeout?

2. Building API tests against a mock. You write the ApiWorkbench collection before the API exists, using the mock to check that the tests themselves are right. When the real API arrives, you change baseUrl and run the same collection against it. The tests were ready on day one.

What a mock does not do is test the real API. A green run against a mock proves that your tests agree with your mock.

Start from the contract

A mock is only useful if it matches the real API's shape: the paths, fields, types and status codes both sides agreed on. Get that from one source, not from memory.

You have	Do this in Mock Studio
An OpenAPI or Swagger file	Import, then the OpenAPI option. Every operation becomes an endpoint. See Import OpenAPI
A Postman collection with saved examples	Import, then the Postman option. Each example becomes a response. See Import from Postman
A running API you may call	Proxy to it and record the responses. See Proxy and record
Only a conversation	Write the endpoints by hand, and share the project file for review

A Mock Studio project is one readable JSON file. Commit it next to the code, so the mock is reviewed and versioned like everything else. See Projects, files and Git.

Make it behave, not only answer

A mock that returns one fixed 200 per endpoint lets you test only the happy path. Use the response strategies to cover the rest.

You want to test	Strategy	Example
A normal answer	Single response	GET /health
Answers that depend on the request	Conditional rules	Right password: 200. Otherwise: 401
Retries and polling	Sequence (round-robin)	503, 503, then 200
An unreliable service	Random / weighted	7 parts success, 3 parts failure
Realistic, varying data	Template tokens	{{params.id}}, {{faker.name}}, {{now}}
Slowness	Latency and jitter	3 seconds, or 0.1 to 1 second
Hard failures	Faults	Dropped connection, empty or malformed body, hang

See Response strategies, Dynamic templating and Latency and faults.

A workflow that works

1. Agree the contract. Write or import the endpoints in Mock Studio. Review the project file with whoever builds the real API.

2. Build both sides against the mock. The app team points at the mock. The test author builds the ApiWorkbench collection against it, with baseUrl as a variable.

3. Add the unhappy answers. Rules for errors, a sequence for retries, a fault or two.

4. Switch to the real API when it exists. Add an environment with the real baseUrl and run the same collection. Differences between the mock and the real API show up as failing tests. Each one is either a bug in the API or a mistake in the contract, and both are worth knowing.

5. Keep the mock. It remains the way to test error handling, and the way new people learn the API.

Using an environment per target makes step 4 a one-click change:

Environment	baseUrl
Mock	http://localhost:4020
Staging	The staging address

Reaching the mock from other devices

• Another program on the same computer: http://localhost: and the port.
• A phone or another computer on the same network: the LAN address on the Share screen, or its QR code.
• A service on the internet, such as a webhook sender: a public tunnel.

See Share on LAN or the internet. A tunnel exposes the mock to anyone who has the address: keep real data out of it and stop the tunnel when you are done.

Watch what the client really sends

The Live log shows each request as it arrives: method, path, headers, body, which endpoint matched and which response went back. It answers questions that are otherwise guesswork:

• Did the app send the Authorization header?
• Is the body shaped the way the API expects?
• Why did this request get the fallback response?

See Live request log.

The limits of a mock

A mock cannot tell you	Because
That the real API works	It is not the real API
That data is stored	Each response is independent; nothing is remembered
That validation is complete	It refuses only what you gave it rules for
That a token is genuine	It checks a header is present, not what is in it
How fast the real API is	Its timing is whatever you set

And one risk: drift. The real API changes and the mock does not. Guard against it by re-importing from the OpenAPI file when it changes, and by running the same collection against both the mock and the real API regularly.

Next steps

• Resilience testing
• Your first mock server
• Sample projects