Negative Test Cases for APIs: The Ones That Find Bugs

The happy path is the part that needs testing least

Most API suites are a wall of happy paths. Send a valid request, get the expected response, go green. It's reassuring, and it's testing the one situation that was always going to work. The valid request with everything in order is the case the developer had in mind while writing the endpoint — of course it passes.

Real clients don't send tidy requests. They send expired tokens, half-built payloads, the wrong type in a field, the same request twice because the network hiccupped. That's where APIs actually break, and it's exactly the set of cases a happy-path suite never covers. Naming that set precisely is what turns an API suite from a green rubber stamp into something that finds bugs.

This is that set: the negative and edge cases worth writing, what each one has to assert, and why they're the cases everyone — tired humans and happy-path generators alike — quietly skips.

The negative categories

Negative cases aren't random bad input. They fall into a handful of categories, and working through them for each endpoint is how you get systematic coverage instead of guessing.

Bad or missing auth. No token, an expired token, a valid token for the wrong user. Assert the correct rejection — a 401 or 403, not a 500, and definitely not a 200 that quietly does the thing anyway.

Malformed body. Broken JSON, the wrong content type, a truncated payload. The endpoint should reject it cleanly with a 400, not fall over.

Missing required fields. Leave out each required field in turn. A good API says which field is missing; a bad one throws a generic error or, worse, saves a half-built record.

Wrong types. A string where a number belongs, a null where a value is required, an array where an object is expected. Type confusion is a rich source of real bugs.

Out-of-range values. A negative quantity, a date in the year 3000, a page size of a million. The endpoint should have limits, and your cases should probe them.

Edge and state cases

Beyond bad input, a second group of cases checks the situations that are technically valid but rarely thought through.

Empty and boundary collections. What does a list endpoint return with zero items — an empty array, or a 404? What about exactly one page, or one item over the page limit? These edges are where off-by-one bugs live.

Pagination. Request past the last page. Ask for a negative offset or an absurd page size. Pagination is fiddly and frequently wrong at its edges.

Idempotency and repeated calls. This is the big one. What happens on the second identical POST? A retried payment must not charge twice. A repeated create should either return the same resource or a clean conflict — never silently make a duplicate. The network will retry requests for you, so your cases have to cover what happens when it does.

What an error case has to assert

A negative case that only checks "it didn't return 200" is barely better than no case. When a request is wrong, three things have to be true, and the case has to assert all three.

The right status. Not just "an error" — the correct error. A malformed body is a 400, bad auth is a 401 or 403, a conflict is a 409. An endpoint that returns 500 for a user's bad input is itself a bug, and a case that accepts any non-200 will miss it.

A useful error body. The response should say what went wrong, specifically enough for a client to act on. "Invalid request" is not that. Assert the shape and content of the error, the same way you'd assert a success body.

That nothing was written. This is the one people forget, and it's where the worst bugs hide. Plenty of endpoints reject a request and leave a side effect behind — a half-created record, a charge with no order, a row updated before validation failed. Your negative case must check that the failed request changed nothing on the server.

Why these cases get skipped

If negative cases are where the bugs are, why are they missing from most suites? Two reasons, and they compound.

The first is human. Writing negative cases is tedious and a little pessimistic — you're imagining all the ways a request could be wrong, one field at a time, at the end of a day when the happy path already passed. It's exactly the work a tired person talks themselves out of: "the happy path works, ship it."

The second is newer. When you ask an AI to generate API tests, it leans toward the happy path too, because that's the most obvious case and the one the endpoint's own description implies. A generator will produce a tidy valid request and a 200 check, and it takes deliberate prompting — and a human reviewer who knows to look — to get the confident, thorough negative coverage that actually finds problems.

Either way, the fix is the same: treat negative and edge cases as a required part of every endpoint's coverage, not an optional extra you add if there's time. Because there's never time, and that's precisely how the bugs ship.

Keeping that coverage honest is a documentation problem as much as a testing one — every negative case needs the same clear expected result as any other, kept in a record a person actually reviews. Tesbo manages and drafts those cases, with a person approving each one; it doesn't run them — the framework and CI stay yours.