Most production incidents in AI features are not the model being wrong. They are the API around it: a missing key that still gets an answer, a 500 that returns an HTML page your code cannot parse, a stream that stops halfway and is shown as complete. These are ordinary API tests, and they are the cheapest tests you will write in this course.
RefundBot's chat endpoint has a written contract. Your tests check it on several builds of the endpoint; some builds break one clause.
The contract
- A request without a valid key gets 401 with a JSON error whose
typeisinvalid_request_error. - A prompt longer than 20,000 characters gets 400 with error code
context_length_exceeded. It is never cut down and answered. - When overloaded it returns 429 with a
Retry-Afterheader in seconds. - Server errors return 500 with a JSON body whose error
typeisserver_error. - A normal reply is never empty, and a streamed reply ends with
data: [DONE].
Making faults happen on purpose
You cannot wait for a real outage. The practice endpoint has a test hook: send the header X-Practice-Fault with 429, 500 or slow (a 4-second delay), and it produces that fault. Real teams build the same kind of hook, or use a mock server, so failure paths can be tested on demand.
Your task
Write one test per clause of the contract above, plus a test that your client gives up on a slow reply instead of hanging. You can work in Python with requests, or in Java with JUnit 5 and REST Assured.