API & Backend Testing

API gateway testing verifies the layer that sits in front of backend services — routing, authentication, rate limiting, request transformation, and load balancing — rather than the services themselves. A correctly-behaving service can still fail end users if the gateway in front of it misroutes or mishandles requests.

API rate limit testing verifies that a system correctly enforces its request-throttling rules — rejecting or delaying requests once a client exceeds its allowed rate — and that legitimate traffic under the limit is never incorrectly blocked. Both failure directions matter: too permissive invites abuse, too strict breaks real users.

API testing verifies the functionality, reliability, and security of an application programming interface directly — sending requests and checking responses — without going through a UI. It's typically faster, more stable, and catches issues closer to their source than testing the same functionality through the frontend.

Authentication testing verifies that a system correctly confirms a user or client's identity — accepting valid credentials, rejecting invalid ones, handling token expiry and refresh correctly, and properly locking out accounts after repeated failed attempts. It's the layer that answers "who is this," distinct from authorization, which answers "what are they allowed to do."

Consumer-driven contract testing has API consumers define the exact requests and responses they expect from a provider, generating a "contract" that's then independently verified against the real provider — catching breaking changes in the provider's own pipeline, before they ever reach a consumer in production.

Contract testing verifies that a service (the provider) and everything that calls it (the consumers) agree on the shape of their API — request format, response fields, status codes — without either side needing the other running to test against. It catches breaking API changes at build time instead of in staging or production.

GraphQL testing verifies a GraphQL API's schema, resolvers, and query behavior — checking that queries and mutations return correctly shaped data, that authorization is enforced per-field where needed, and that deeply nested or complex queries don't cause performance or resource problems.

An HTTP status code is the three-digit number a server returns with every response, indicating the general outcome of a request — 200 for success, 404 for not found, 500 for a server error. Verifying the correct status code for each scenario is one of the most basic, high-value assertions in API testing.

Idempotency testing verifies that making the same request multiple times produces the same result as making it once — critical for operations like payments or order creation, where a retried request (due to a network timeout, a client retry, a duplicate click) must not cause duplicate side effects.

JSON Schema is a specification for describing the structure, types, and constraints of JSON data — what fields are required, what types they must be, valid value ranges — used in testing to automatically validate that an API response matches its documented contract, rather than checking each field by hand.

Mocking replaces a real dependency — a service, a database, an external API — with a fake, controllable stand-in during a test, so the test can run in isolation, quickly and predictably, without needing the real dependency available or behaving unpredictably.

A request/response assertion checks that an API's actual response — status code, headers, body content and structure — matches what was expected for a given request. It's the core mechanism that turns "I sent a request and got something back" into an actual pass/fail test result.

REST API testing verifies APIs built on the REST architectural style — checking that endpoints correctly handle standard HTTP methods (GET, POST, PUT, DELETE), return appropriate status codes, and manage resources as the REST model expects (predictable URLs, stateless requests, correct use of HTTP semantics).

Schema validation checks that data conforms to a predefined structure — required fields present, correct types, values within allowed constraints — automatically rejecting or flagging anything that doesn't match, rather than relying on manual, field-by-field inspection.

Service virtualization creates a simulated version of a dependent system's behavior — mimicking its responses, timing, and even failure modes — so testing can proceed without the real dependency being available, stable, or cheap to call repeatedly. It's mocking's more sophisticated, environment-level cousin.

SOAP testing verifies APIs built on the SOAP protocol — an XML-based messaging standard with a strict, formally defined contract (WSDL) — checking that requests and responses conform to that contract and that the service handles the protocol's built-in error and fault-handling conventions correctly.

Stubbing provides a hard-coded, canned response in place of a real dependency's behavior — simpler than a full mock, since a stub doesn't verify how it was called, it just returns a fixed answer whenever it's invoked. It's used to isolate the code under test from dependencies that aren't relevant to what's actually being tested.

Webhook testing verifies that a system correctly sends event notifications to a configured external URL when something happens — an order is placed, a payment completes — and that it handles delivery failures, retries, and payload correctness properly. Unlike a normal API call, webhooks are triggered by the server, not requested by the client.