Mock Servers

Prev Next

Every lesson so far has assumed the RecipeBox backend actually exists and answers requests. In practice, a tester is often handed an API contract — the agreed shape of requests and responses — weeks before the real backend is finished. Waiting until the backend team ships code before writing a single test wastes that time. A mock server is a fake API that returns canned, pre-defined responses instead of running real logic, so you can build and run tests against the agreed contract right away.

What a Mock Server Actually Is

Real RecipeBox API	Mock Server
Runs real application logic, a real database, real validation	Returns a fixed, pre-saved response for a given request — no logic, no database
Response can change based on real data (recipe 42 might get edited or deleted)	Response is always the same for the same request — perfectly predictable
Might not exist yet, or might be down/unstable while being built	Exists the moment you save an example response — always up
Testing it proves the real implementation works	Testing it proves your Postman tests and the agreed contract shape are correct

A mock server never proves the real RecipeBox backend works — only a real request to the real backend can do that. What it proves is that your tests, and the contract everyone agreed on, are internally consistent — valuable on its own, and something you can start doing on day one.

Step 1: Save Example Responses on Your Requests

A mock server is built from a collection's saved examples — a request paired with one or more example responses. Open Get Recipe by ID, click Save as Example (or the "..." menu next to the request → Add Example), and fill in the response Postman should return:

// Example response saved on GET {{baseUrl}}/recipes/42 — status 200
{
  "id": 42,
  "title": "Paneer Butter Masala",
  "ingredients": ["paneer", "butter", "tomato puree", "cream"],
  "steps": ["Marinate paneer", "Prepare gravy", "Simmer and combine"],
  "photoUri": null,
  "category": "Dinner",
  "prepMinutes": 20,
  "isPublished": true
}

Add a second example on the same request for the error path — say, a 404 for a recipe id that doesn't exist:

// Example response saved on GET {{baseUrl}}/recipes/9999 — status 404
{
  "error": "Recipe not found"
}

Do this across the requests that matter — Get Recipe by ID, Search Recipes, Create Recipe — and the collection now fully documents the agreed contract: exactly what each endpoint returns, for both success and failure.

Step 2: Creating the Mock Server

From the RecipeBox API collection's "..." menu, choose Mock Collection (or use the dedicated Mock Servers tab in Postman).
Give it a name, e.g. RecipeBox Mock, and choose whether it's private or public.
Postman generates a mock URL, something like https://a1b2c3d4-....mock.pstmn.io.
Point a request at it directly, or — better — set an environment's baseUrl to the mock URL so every existing request in the collection works against the mock with zero changes.

Send GET {{baseUrl}}/recipes/42 against the mock URL and Postman returns the exact saved example — the same 200 body shown above — with no real backend involved at all. Request the same path with the id from the 404 example, and it returns that error response instead. Postman matches incoming mock requests to the closest saved example by method and URL.

Why This Matters Specifically for Testers

The RecipeBox backend team estimates two more sprints before POST /recipes is actually deployed. Without a mock, testing (and the frontend team's UI work) is blocked for two sprints. With a mock server built from the agreed contract, you can:

What the mock unblocks	Why it's valuable now, not later
Writing and running your full Postman test suite (assertions, schema checks, chaining) today	Every test is already written and passing against the contract the day the real backend ships — instead of starting test-writing from zero
Frontend developers building the "Create Recipe" screen against the mock	UI work doesn't sit idle waiting on the backend team
Catching contract disagreements early	If your schema-validated tests fail against the real backend once it ships, that's a sign the backend and the agreed contract drifted apart — a bug worth reporting either way

Note: A mock server response is always the exact saved example — it can't run real business logic like actually persisting a created recipe or applying a real search filter. Once the real backend is ready, re-point baseUrl back to it and re-run the same collection; a passing suite there is the test that actually matters.

Next: You've now covered the full Postman testing workflow end to end. API Testing Best Practices ties it together into a practical checklist for writing test suites that hold up over time.

Prev Next