Core Code
Core Code Modern Dev Handbook

Mocking & Environments

Mock servers, test data, and environment-based configs.
On this page

Why mocking matters

Mocking lets frontend and integration work continue even when the real backend is not ready, unstable, or expensive to call. It also enables reliable tests.

Environment-based configuration

Use environments to switch base URLs, tokens, and feature flags without changing code. Keep “dev”, “staging”, and “prod” cleanly separated.

Example environment variables (concept)

DEV_BASE_URL=http://localhost:8080
STAGING_BASE_URL=https://staging.example.com
PROD_BASE_URL=https://api.example.com

Mock server approaches

  • Postman mock servers: quick to share with a team
  • Static JSON fixtures: simplest for UI development
  • Local mock API: small Node/PHP service returning canned responses
  • Contract-based mocks: generated from OpenAPI/Schema

Mocking failure cases

Mock errors on purpose: 401, 403, 404, 409, 422, 429, 500. Real-world clients must handle failures gracefully.

Example: mock 422 response

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
  "title": "Validation failed",
  "status": 422,
  "errors": { "email": ["Invalid email"] }
}

Keeping mocks honest

  • Version your mocks with the API.
  • Prefer contract-driven mocks (OpenAPI) when possible.
  • Run a small set of integration tests against real staging.

Checklist

  • Dev/staging/prod environments are separated.
  • Mocks include both success and failure cases.
  • Mimic real response shapes and status codes.