AI Coding Agents
Testing
API rate limit tests for agent-generated services
September 28, 2026 - 2 minute read
API rate limit testing checks whether a service enforces request quotas without breaking well-behaved clients. Coding agent changes can alter middleware order, identity keys, shared counters, or retry behavior in a small diff. Those details determine whether one tenant can consume another tenant’s capacity or whether clients recover cleanly after throttling.
The HTTP standard defines status code 429 for requests rejected because too many arrived in a given period. RFC 6585 also allows a Retry-After header that tells the client when to try again. A useful test suite checks the service contract around that response rather than asserting only that one request eventually fails.
Build API rate limit tests around identities
Start by identifying the key that owns the quota. It may be an API key, user, organization, IP address, route, or combination of those values. Then run requests from two independent identities. Exhausting one quota must not reduce the other identity’s allowance unless the documented policy intentionally uses a shared pool.
Test authenticated and unauthenticated paths separately. A fallback from a missing user ID to a shared anonymous key can turn a local bug into a broad outage. Also check privileged identities and internal callers. Bypasses should be explicit, narrow, and covered by policy tests.
Use a deterministic clock or a short test-only window. Sleeping until a production-sized window resets makes the suite slow and unreliable.
Verify API rate limit responses
Exercise the boundary with requests immediately below, at, and above the configured quota. Confirm that accepted requests keep their normal response shape. Rejected requests should return 429, a stable error body, and any retry metadata promised by the API documentation.
Parse Retry-After as both forms permitted by HTTP, either a delay in seconds or an HTTP date. Test a malformed value too. Client code should apply bounded backoff rather than retrying in a tight loop. If several workers share a quota, send requests concurrently so the test can expose non-atomic counter updates.
Rate limits often depend on a distributed store. Include failure cases for a timeout or unavailable counter backend. The expected behavior should be a deliberate fail-open or fail-closed policy, not an accidental result of an uncaught exception.
Give a coding agent observable acceptance criteria
A coding agent needs an executable contract. State the quota owner, window, threshold, response code, retry behavior, concurrency level, and reset condition. Include the command that runs the focused tests and the location of existing fixtures.
Factory’s Automated Code Review supports repository-specific review guidance. A team can require reviewers to flag rate-limit changes that lack cross-tenant isolation, boundary tests, or retry evidence. The review should inspect the changed policy and tests together because either can encode the wrong limit.
Review API rate limit test evidence
When an API rate limit test fails, capture which identity made each request, the observed counter state, and the response metadata. Avoid recording credentials or complete request bodies. The evidence should let a reviewer distinguish a policy mismatch from timing noise.
Keep load testing separate from contract testing. Contract tests prove behavior at a controlled boundary. Load tests measure how the limiter and its backing store behave under sustained demand. Both matter, but they answer different questions.
