Control which stub wins when mock rules overlap
Make stub precedence explicit in WireMock, MSW and nock, and fail a test when a stub never answers, so a catch-all cannot hide the specific case you just added.
How-to › Section 10
Test and mock integrations#
Mocks, record-and-replay, contract and spec-driven tests, and layered SDK test suites, for APIs you ship and APIs you do not own.
16 guides in 3 topics. Every guide compares its approaches and shows the output its commands printed.
Mock an API 7 guides
Standing in for the real API: Prism from an OpenAPI document, WireMock, MSW, nock, Mockoon, vendor sandboxes, record-and-replay (vcrpy, VCR, Polly.JS, go-vcr, responses, httptest), fault injection (Toxiproxy, chaos flags), and in-SDK mocks (the sdkgen test feature for an in-memory API and netsim for injected latency, 429s and outages as options).
Mock a generated SDK in your application tests
Run one set of assertions about your code against a vendor SDK four ways, then bump the SDK a minor version and see which strategy noticed the change.
Run a local mock API for frontend development with Mockoon
Describe routes, status codes, and delays in one Mockoon environment file, run it headless with the CLI, and point the screen you are building at it.
Run an in-memory mock of your API inside SDK tests
Build the client in test mode, seed it with records, and let the generated SDK answer its own calls from memory instead of reaching the network.
Serve your OpenAPI examples as mock responses
Wire the examples in your OpenAPI description to what the mock server returns, so the docs, the tests and the mock all show one payload.
Simulate slow and broken networks with Toxiproxy
Put Toxiproxy between a client and its dependency, slow, stall and cut the connection from the test, and prove each call fails at its time budget.
Stub outbound HTTP calls in Node tests with nock
Intercept outbound requests in-process, assert on what your code sent as well as received, and turn off real network access so an unstubbed call fails.
Run contract and spec tests 7 guides
Proving the implementation matches the description: Pact consumer-driven contracts (for an SDK consumer and for a vendor API you call), Schemathesis and Dredd property tests against a spec, Specmatic and Microcks, response validation middleware at runtime, and message contracts for service messages (seneca-msg-test as one option next to Pact message contracts).
Choose consumer-driven or spec-driven contract tests
Pick a contract style by what it fails on: the fields one consumer reads, or everything the published document describes, including the unused parts.
Contract test an API you do not own
Write down the fields your integration reads, check a recorded response against them, and run the same check against the live API on a schedule.
Contract test messages between services
Pin the body and the routing key of an event in a consumer contract, verify the publisher in CI, and see the three tools catch, or miss, a renamed topic.
Publish and tag pacts in a Pact Broker
Run the broker on Docker and Postgres, publish each pact under its commit and branch, and record deployments so the broker knows what runs where.
Run an OpenAPI document as a contract test with Specmatic
Keep one JSON example per documented response beside the document, run Specmatic in strict mode against the service, and fail the build when one is missing.
Test stateful endpoints with Dredd hooks
Make Dredd pass for reads and deletes that need a record first, without loosening an assertion, and fail loudly when a hook names a transaction that has gone.
Validate responses against the OpenAPI document at runtime
Build a validator from the response schema in your OpenAPI document and run it over real responses, so a service that stops matching its description fails.
Run SDK test suites 2 guides
Layered SDK testing: unit tests per language, integration tests in a sandbox account, live suites with real credentials under rate limits, CI matrices across language versions, doc examples executed as tests, flaky-test policy.
Layer unit, integration, and live tests for an SDK
Split an SDK suite into unit tests on an injected transport, integration tests against a sandbox, and a guarded live suite. Each layer gets a command and a trigger.
Seed a sandbox account for SDK integration tests
Create every record an integration suite needs under a run id, delete them newest first in a hook that runs on failure too, and sweep what earlier runs left.
Generate the client instead of writing it#
Retries, timeouts, pagination and auth are the same problems in every client. Voxgig generates them from your OpenAPI description, in 23 languages, from one model.