Design negative API tests for validation, throttling and retry limits.
Instruction: Give response sequences, expected attempts, timing and final outcomes. Separate server validation from client retry behavior.
A fictional read-only GET /records/R7?limit=2 returns 200 with {"id": "R7", "items": ["I1", "I2"]}. The owned record has two ordered items; limit=1 returns only I1, while limit=50 returns both. Client retry examples below all use limit=2 and require the exact seeded body. The service gives 400 for invalid limit, 401 without authentication, 403 for a denied role and 404 for a missing record; none may contain protected record data. Limit is an integer from 1 through 50. The client retries only 429, 503 and transport timeouts. There are at most three total attempts including the first, with one eight-second deadline from the first start. Requests must honor the remaining budget. Success observed at or after the deadline is late.
For 503 or timeout, wait one second before attempt two and two seconds before attempt three. For 429, use nonnegative whole-number Retry-After seconds; missing or malformed values default to one second. Do not sleep or start another attempt if the delay consumes the remaining budget. Unexpected statuses and malformed success bodies fail immediately. The retry fixture has an injected monotonic clock and scripted transport; responses take zero simulated time unless stated otherwise. Separate owned service fixtures are available for validation/access tests. No real accounts or production load testing are permitted.
Updated
Official answer available
Read the opening below, then unlock the full answer and practical guidance.
I would separate service behavior from client policy. With owned service fixtures I would send invalid limits, missing credentials, a denied role and a missing record, checking the specified status and absence of protected data...
Related Questions
-
easy
-
easy
-
easy
-
easy
-
easy
-
easy