hardDesignScenarioMidSeniorStaff
You own the API test suite for a service from scratch. How do you structure it, and what do you mock?
8 min readUpdated 2026-08-15
Answer
Short answer
Separate contract tests, which check shape and backwards compatibility cheaply, from integration tests that exercise real behaviour across real dependencies. Make every test create and own its data so the suite is re-runnable, spend most of your negative cases on authorisation and malformed input.
Was this answer helpful?
Likely follow-ups
- Your consumer contract passes and the integration fails. What did each layer actually tell you?
- How do you test that a change is backwards compatible for a client you cannot see?
- The service publishes events as well as responding to requests. What does that add to the suite?
- Where would you put a test for a 30-second downstream timeout, and how would you produce one?
Related questions
- Your consumer-driven contract test passes in CI, but production rejects a request because a supposedly optional field is missing. What did the contract testing actually miss?hardAlso on contract-testing and api-testing4 min
- Your API suite runs on every commit against a shared database. How do you keep the tests from corrupting each other's data?hardAlso on api-testing and test-data6 min
- Two teams own two services that talk to each other. How do you stop one breaking the other without running both together in a shared environment?mediumAlso on contract-testing and api-testing4 min
- You must ingest all of English Wikipedia every day, and the source does not want to be hammered. What runs, how often, and what do you do about the run that fails at hour six?hardAlso on idempotency6 min