Make the input explicit.
Missing, null and empty are different questions. Write the case down before you trust the answer.
A SMALL TOOLKIT FOR BETTER API QUESTIONSINPUT → EXPECTATION → RESULT
Ask better
of your API.
A request is a question.
A fixture makes the answer testable.
Build the habit right here.
● EDGEKIT / REQUEST BENCHOffline sample fixtures
01 / REQUEST
GET
/catalogEXPECTED BEHAVIOUR
Local evaluation. No HTTP request is sent.Pagination and empty result
02 / RESPONSE
content-type: application/json x-example-mode: offline cache-control: no-store
Ready to evaluate a sample fixture.
One focused workbench. Nothing to connect.Open the full workbench ↗
Keep the expectation stable.
Check the contract, not an incidental timestamp. A small fixture should survive an unrelated change.
Read the error, too.
The wrong input is part of the interface. A predictable error is as useful as a successful response.
Recipes for the next request.
01 / EdgeKit
Build maintainable request fixtures
Examples that remain useful after the first successful call.
Read the guide ↗02 / EdgeKitTest the edges of an API contract
A focused checklist for request and response validation.
Read the guide ↗03 / EdgeKitReview an API change for compatibility
How to distinguish additive changes from surprising behaviour.
Read the guide ↗A few useful answers
Does a fixture need a live API?
A fixture can document an interface independently. Executing it requires a suitable endpoint and separately supplied credentials.
Should response checks match every field?
Check the contract, not incidental formatting. Allow documented optional fields and generated values while validating the parts consumers rely on.
Can production records be used as examples?
Synthetic examples are preferable. Remove secrets and personal information before any request or response is shared.
What belongs in a minimal fixture set?
One normal request, a meaningful empty case, invalid input and a boundary case for the operation. Expand it when a real regression reveals a gap.