Skip to documentation

Guide · Verification

Available

Prove the behavior your application depends on

A configured response is not evidence that a client handles it. Use safe previews for authoring, live requests for runtime behavior, and application-level assertions for retries, loading, idempotency, and observability.

In this guide

  • Use isolated dry-runs correctly
  • Make randomness and time deterministic
  • Cover success and failure journeys
  • Debug the winner and every near miss

Prerequisites

  • A DotMock workspace you can access
  • The API ID in $API_ID and its published runtime URL in $MOCK_URL when the example calls the mock
On this page
  1. Know what a dry-run guarantees
  2. Fix seed, clock, and state
  3. Cover the contract, not only 200
  4. Assert protocol-native details
  5. Run the application against the scenario
  6. Inspect near misses before broadening a matcher

Know what a dry-run guarantees

Dry-runs use the actual matcher and template runtime. Before actions and inline mutations run in an isolated state overlay, and the exact proposed state diff is returned. No persistent state, webhook delivery, proxy request, or external callout occurs.

  • Response status, headers, and body are rendered
  • The winning endpoint, operation, fixture, or event is identified
  • Diagnostics explain disabled side effects
  • Validation and render failures commit nothing

Fix seed, clock, and state

Use a fixed seed for generated values and weighted choices, a virtual clock for time conditions, and an isolated run ID for state. Seed a known queue or snapshot before sequence-sensitive tests.

bash
dotmock --json config simulate \
  --api "$API_ID" \
  --request @request.json \
  --seed 42 \
  --at 2026-01-15T09:00:00Z

Cover the contract, not only 200

Choose scenarios from the dependency's real contract and the risks in your application. Give CI explicit matchers instead of relying on fault probability.

  • Success and empty results
  • Invalid request and authentication failure
  • Forbidden and not found
  • Conflict and idempotency replay
  • Rate limit and retry-after
  • Slow response, timeout, and disconnect
  • Malformed payload or stream
  • Upstream 500, 502, 503, and 504
  • Stateful create, read, update, delete, and ordered sequences

Assert protocol-native details

A valid HTTP status is not enough for every shipped workflow. Assert the pieces clients actually parse.

  • REST: status, headers, schema, body, state, and response hooks
  • GraphQL: data/errors shape, aliases, validation, operation winner, and subscription sequence
  • gRPC: descriptor validation, initial metadata, ordered messages, trailers, status, state diff, and cancellation
  • LLM: provider envelope, tool calls, structured JSON, token chunks, terminal event, and disconnect
  • Webhook: rendered body, signature, headers, target, attempt history, retry lineage, and latency

Run the application against the scenario

Point only the development or test base URL at DotMock. Exercise the real user or service journey, then verify loading, retry, timeout, error copy, fallback, idempotency, logs, traces, and metrics. Do not claim resilience because a mock was configured.

Inspect near misses before broadening a matcher

Review each candidate and failed branch, including field-level differences, context, state before and after, selected response, timeline, seed, and revision. A broad catch-all can hide a contract bug and make an unrelated response look successful.

bash
dotmock --json list traffic --api "$API_ID" --limit 100
dotmock --json get stats --api "$API_ID"