What Is a Mock API? Mock Servers for API Testing

This is lesson 6.1 of Test Data, Mocks and End-to-End API Testing. It starts the track with the test double you'll use most, and it assumes you've made a request to an API before. If not, start with what an API is.

What is mock API, in plain terms?

So, what is mock API testing about? A mock API is a stand-in server that answers requests the way the real API is documented to, without the real service behind it. You point a client, a frontend or a test at the mock's URL instead of the real one, and it replies with the status codes and bodies the API's contract describes.

Teams reach for one in three situations:

• The service doesn't exist yet. The spec is agreed, the backend is two sprints away, and the frontend team still needs something to call.
• The service exists but you can't rely on it. A partner API with a rate limit, a payment provider's test environment that goes down on Fridays, a team whose staging is always mid-deploy.
• You need an answer the real service rarely gives. A 503, a two-second delay, an empty list.

What is mocking in API testing, exactly?

In API testing, mocking means replacing a dependency of the thing you're testing, not the thing itself. If you're testing an orders service that calls a users service, you mock the users service. Mock the orders service too and you're testing the mock.

That last row matters. A mock never tells you whether the real API works. It tells you whether your code copes with the answers the API promises to give.

An API mocking example against the sandbox store

The sandbox store is a real API with users, products and orders. Ask it for the Wireless Mouse:

curl -X GET 'https://demo.totalshiftleft.ai/api/v1/products/aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

The real answer carries real data: "name": "Wireless Mouse", "price": 24.99, "stock": 150, inside { "success": true, "data": { ... } }.

Now generate a mock for the same endpoint from the store's spec, /openapi/rest.json. The spec has no example values, so a mock built from it fills each field with a placeholder of the right type (abridged here):

{
  "success": true,
  "data": {
    "id": "<a fixed UUID>",
    "name": "string",
    "price": 0,
    "stock": 0
  }
}

The status is right (200), the shape is right, the types are right. The values are not real, and one of them, a price of 0, is a value the store would refuse if you tried to create a product with it: the spec says a price must be greater than zero. That's the honest limit of any spec-built mock. It reproduces the contract, not the business.

Static, dynamic and conditional mocks

Mocks come in a few strengths. Most mocking tools offer some mix of these:

• Static: one canned response per endpoint. Fast to set up, useful for "does my page render a product".
• Dynamic: the response is built per request, for example echoing the id from the path or generating a fresh UUID and timestamp.
• Conditional: different responses for different requests, such as a 404 when a query parameter says so, or a 400 when the body has no email.
• With latency: a fixed delay before answering, so you can test timeouts and loading states.
• Stateful: a POST followed by a GET returns what you posted. This is the hardest kind to build and maintain, and many teams skip it in favour of testing state against the real service.

API mocking for testing: what a mock can and can't prove

The right-hand column is the job of other tests: contract and schema checks against the real service, functional tests, and performance tests. Mocks speed up the left-hand column; they don't replace the right-hand one.

Common mistakes with mock APIs

1. Mocking the system under test. If every call in a test hits a mock, the test can only fail when the mock is wrong.
2. Letting the mock drift from the spec. The real API adds a required field; the mock, written by hand six months ago, doesn't. Regenerate mocks when the spec changes.
3. Asserting real values against a mock. A check that the price equals 24.99 will fail against a placeholder of 0. Against a mock, assert status, fields and types.
4. Forgetting which one a test is pointed at. A suite that quietly runs against the mock in CI will pass forever. Make the target visible in the environment name.
5. Assuming the mock intercepts calls. Most mock servers answer only requests sent to their own URL. Your test goes there only if you point it there.

Mock servers in Shift-Left API

In Shift-Left API, you spin up mock servers from the spec you already imported. Mock servers are in every edition; the free edition holds up to 50 mocks.

1. Import https://demo.totalshiftleft.ai/openapi/rest.json into a project.
2. Click Mocks in the top bar and select the project.
3. Click Generate Mock, tick the Users feature, and click Generate Mocks. You get one mock per endpoint, each linked to it and active.
4. Click Test Mock on one of them. It answers with the success status the spec documents and a body built from the response schema: the spec's own examples where it has them, typed placeholders where it doesn't. No AI is involved, so the mock never invents values the contract doesn't describe.
5. Click Start Mock Server. The panel reads Mock Server Running and gives a path-based URL and a subdomain URL.

A few facts worth knowing before you rely on it:

• One Generate Mock call can cover up to 500 endpoints, from OpenAPI, WSDL or GraphQL definitions.
• In the response editor you can add response variants with conditions on query, header or body fields (10 operators), dynamic templates that echo the request or generate UUIDs and timestamps, and a per-response delay in milliseconds.
• The mock server doesn't intercept test runs, and it isn't stateful: a POST doesn't change what a later GET returns.

To send an existing test to the mock, you give an environment the mock's URL and make it the default. Lesson 9.9 walks through that end to end, and the mock server feature page lists what the mock editor supports.

Try it yourself

Import the sandbox spec into a new project. Open Mocks, generate mocks for Users, and click Test Mock on one. Then click Start Mock Server and copy the path-based URL. Compare the mock's body with the real answer from the request above.

Recap

• What is mock API? A stand-in that answers the way the real API's contract says it will, so you can test before the service exists or while it's unreliable.
• What is mocking in API testing: replacing a dependency of the code under test, never the code itself, and asserting on shape and status rather than real values.
• API mocking for testing speeds up client and integration work; contract, functional and performance tests still have to run against the real service.

For a longer look at when teams mock and which tools they use, read what is API mocking, and how and when to mock APIs.

Next: lesson 6.2, API mocking and stubbing, where you sort mocks, stubs and service virtualization apart.