Skip to main content

Common Mistakes in API Testing

Prerequisites: You should already understand every module in Sections 2–7 of this path. Leads to: After this, you'll be ready for the API Testing Capstone.

Every module in this path named mistakes specific to its own concern. This module steps back and asks which mistakes recur across concerns, visible only once you've seen the whole path. These aren't new rules — they're the handful of underlying habits that, left unchecked, undermine almost any concern this path taught.

Pattern 1: Trusting a Response Without Trusting the Request That Produced It​

A tester confirms a response looks correct without first confirming the request that generated it was actually well-formed for the scenario under test.

How this leads to an escaped defect: exactly API Requests and Responses' opening memo-field example — a copied, modified test request still carrying a leftover empty-string field instead of a genuinely absent one, silently testing the wrong scenario while still "passing."

Prevention: verify the request itself, especially in copied or reused test data, before treating a response as evidence of anything.

Pattern 2: Testing Only What a UI Would Send, Not What the API Actually Accepts​

A tester limits API testing to whatever requests the current UI happens to generate, rather than testing the API's actual, broader surface directly.

How this leads to an escaped defect: What Is API Testing?'s beneficiary example — a missing-field case the UI's client-side validation blocks, but which is fully reachable by anything else calling the same API, went untested because no one tested beyond what the UI happened to allow.

Prevention: test the API's actual documented (and, where relevant, undocumented) surface directly, independent of what any one client currently sends.

Pattern 3: Confirming a Value Range's Presence Without Testing an Invalid Value Within It​

A tester confirms a parameter or field accepts valid input without testing what happens when it receives a value outside its intended set.

How this leads to an escaped defect: Headers, Parameters, and Payload Validation's status=archived example — an invalid filter value silently ignored and treated as if absent, invisible to any test that only confirmed the parameter's presence worked.

Prevention: for every constrained field or parameter, test an actual invalid value, not just its presence, absence, or a valid example.

Pattern 4: Testing a Retry's "Success" Without Checking Whether Its Effect Was Duplicated​

A tester confirms a retried request completes successfully without checking whether the underlying effect (a charge, a transfer, a record) happened once or twice.

How this leads to an escaped defect: Idempotency, Retry Logic, and Duplicate Request Prevention's opening fund-transfer example — a retry that "succeeded" while silently duplicating a real financial transaction, invisible to anyone checking only the retried request's own response.

Prevention: after any retry test, check the full resulting state, not just whether the retried request itself returned success.

Pattern 5: Treating Security-Adjacent Findings as Someone Else's Responsibility​

A tester assumes BOLA, excessive data exposure, and similar findings belong exclusively to a dedicated security function, outside ordinary functional testing's scope.

How this leads to an escaped defect: API Security Fundamentals's loan-status example — an excessive-data-exposure defect caught using nothing more than the same field-by-field comparison discipline this path teaches from Section 2 onward, missed only because no one thought to apply that existing skill with a security-relevant question in mind.

Prevention: apply the precise-reading and boundary-testing habits this path already builds to security-relevant questions as a matter of course, not as separate, specialized work requiring a different skill set entirely.

Pattern 6: Assuming a Passing Test on One Endpoint Generalizes to a Similar Endpoint​

A tester confirms a concern (authentication enforcement, idempotency, CORS configuration) works correctly on one endpoint and assumes a similar endpoint in the same API behaves the same way.

How this leads to an escaped defect: API Authentication's opening example — expired-token rejection working correctly on one endpoint while a different endpoint in the same API accepted the same expired token, an inconsistency invisible to anyone who tested only once and assumed the result applied everywhere.

Prevention: test each concern on each individually relevant endpoint, treating a passing result elsewhere as a reason for optimism, not as evidence.

Every pattern above has the same underlying shape: a shortcut that feels reasonable in the specific moment it's taken — trusting a response because it looks right, assuming a passing test elsewhere generalizes, treating a security-relevant check as out of scope. Recognizing the temptation itself as a signal worth pausing on, not just knowing the list of patterns, is what actually prevents them from recurring.

Key Takeaways​

  • Six recurring patterns cut across this path's individual concerns: trusting an unverified request, testing only what a UI sends, skipping invalid-value testing, checking retry success without duplication, treating security findings as out of scope, and generalizing one endpoint's passing result to another.
  • Each pattern is a shortcut that feels reasonable in the specific moment it's taken — recognizing the moment of temptation is the actual skill, more than memorizing the list.
  • Every pattern traces back to a real, worked defect example from earlier in this path — these aren't hypothetical risks, they're patterns that have already produced real, specific defects throughout this path's own teaching examples.
  • Prevention in every case is a specific, learnable habit, not a vague call for more thoroughness.

What You Just Learned​

  • Six mistake patterns that recur across this path's individual testing concerns, not within any single one
  • How each pattern, left unchecked, produced a real, specific defect in this path's own worked examples
  • The specific prevention habit for each pattern
  • Why recognizing the moment of temptation to take a shortcut matters more than memorizing a list of mistakes

Next: API Testing Capstone

Interview Questions​

Q1: What's a common mistake you've seen (or made) in API testing, and how would you prevent it?

What to look for: A specific, real pattern (not a generic "not testing enough") with a concrete prevention habit attached — ideally one of this module's six, explained in the candidate's own words, showing genuine understanding rather than a memorized list.

Q2: Why might a passing test on one API endpoint not tell you much about a similar endpoint in the same system?

What to look for: A candidate who recognizes that concerns like authentication enforcement, idempotency, and CORS configuration are typically implemented per endpoint and can be inconsistent, directly citing Pattern 6's reasoning rather than assuming uniform implementation across an API.

Glossary​

Escaped Defect: A defect that reached production despite testing having occurred, typically traceable to a specific gap in test design rather than an absence of testing effort.

API Testing Anti-Pattern: A recurring, specific way API testing goes wrong, distinct from a one-off mistake — recognizable and preventable once named.

Quick Revision​

Remember these five points:

✓ Verify the request itself, not just the response, especially in copied or reused test data.

✓ Test the API's actual surface directly, not just what the current UI happens to send.

✓ Test an actual invalid value for every constrained field or parameter, not just its presence or absence.

✓ After any retry test, check the full resulting state, not just whether the retried request itself succeeded.

✓ Test each concern on each individually relevant endpoint — a passing result elsewhere is not evidence.