Testing code that calls a third-party API
How you fake external HTTP without real network calls.
Intercept at the HTTP boundary (nock) or run a local mock server; cover success, errors, timeouts, and assert request shape.
What's really being asked
Whether you can choose the right interception point so your tests exercise as much real code as possible while staying offline and deterministic, and whether you test failure modes, not just the happy path.
The full answer
Two broad techniques. First, intercept at the HTTP transport boundary using a library like nock, which patches the http/https layer and matches outgoing requests, letting you script responses, status codes, delays, and bodies. This keeps your real client (axios/fetch), serialization, auth headers, retry, and error-mapping code under test. Second, run a standalone local mock server (WireMock, Mockoon, or an Express stub) the service points at via a configurable base URL; this is closer to a real network round trip and is reusable across languages, but adds process management. The weaker option is mocking your own client wrapper module with jest.mock; it is the simplest but bypasses the actual request construction and HTTP handling, so bugs in headers or serialization slip through. Whatever you pick, test 2xx success, 4xx validation errors, 5xx and timeouts, and assert the outgoing request matches the contract (idempotency keys for payments, for example).
The mistakes people make
Mocking the highest-level wrapper and claiming the integration is tested; making real calls to a third-party sandbox in CI (slow, flaky, rate-limited, requires secrets); only testing the success path and ignoring timeouts and error codes.
What usually comes next
How do you test retry and backoff logic deterministically? How do you keep mocks honest against contract drift (contract tests, recorded fixtures)? Why are idempotency keys critical for payment retries?
A concrete example
For a Stripe charge service, use nock to intercept POST to the charges endpoint: assert one test returns a successful charge, another returns a card_declined 402, and a third delays past the timeout so you verify the retry and surfaced error.
Interview question
What is the main drawback of testing a third-party integration by mocking your own client wrapper module rather than intercepting at the HTTP layer?
- a.It cannot simulate a successful response
- b.It bypasses request construction and the HTTP layer, leaving header and serialization bugs untestedCorrect
- c.It requires a running third-party sandbox account
- d.It makes tests slower than real network calls
Why? this is the answer
Mocking your own wrapper skips the real request-building and transport code, so serialization or header bugs go uncaught. It is actually faster than real calls and needs no sandbox account.
Just read this? Test yourself on what you have been reading.
Read the original → github.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on nodejs — each one lists the topics its interview covers.
See open roles