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.
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.
7 guides in 2 topics. Every guide compares its approaches and shows the output its commands printed.
Mock an API 4 guides
Standing in for the real thing: 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).
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.
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 3 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.
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.
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.