Break the workflow before users do

Pick failures that can change the outcome.

Submit an empty message, an invalid email, a message over the limit, and a repeated request. Try an admin action while signed out. Each case should explain what happened and should leave existing records intact.

Next, test a model refusal, incomplete output, a provider error, and a timeout. Those failures should not make the public visitor resubmit their enquiry: it was already saved before the operator requested a draft.

npm test

Use fixtures for failures.

The reference injects fetchImpl into generateSummary, so tests can return a deliberately broken provider response without using a paid key. Read the AI test to see the exact URL, request settings, schema, and output limit being asserted.

Add a fixture that returns a plausible summary with a made-up evidence excerpt. parseSummary should reject it. Then add an assertion that the original message is still present after that failure. This verifies the workflow, not only the parser.

Write a small failure table.

For every important failure, record the trigger, visitor or operator message, stored state, and safe next action. A rate-limit response may require waiting, while a billing or credential problem requires configuration changes. A generic retry loop cannot solve all three.

Test HTML-like input as literal text. The app uses textContent for enquiry content and never inserts it as HTML. A string containing a script tag belongs in the visible message, not in the page’s executable code.