Failing Test First — Bug Reproduction

Before we fix this bug, we pin it down. Write the smallest possible test that fails BECAUSE of this bug and will pass once it is fixed. No fix yet — the test is the deliverable. Bug report: {{bug_report}} Relevant code: ```{{language}} {{code}} ``` Test framework: {{framework}} Requirements for the repro test: 1. **Minimal** — strip the report's scenario to the essential trigger. If the report says "crashes when exporting 400 orders with mixed currencies", find whether the trigger is the count, the mixing, or one weird order — write the test at that level. If you cannot tell from the code, write your best candidate and list the 2–3 variants to try if it unexpectedly passes. 2. **Deterministic** — take control of every source of nondeterminism on the code path: freeze the clock (especially near midnight/DST if dates are involved), seed or inject randomness, replace network/filesystem with fakes, pin locale and timezone explicitly. 3. **Asserts the right thing** — the assertion states the CORRECT expected behavior (so the test is green after the fix), not the current broken behavior. Assert on observable outcome, not implementation internals. 4. **Named as documentation** — the test name states the rule being violated: `refund_uses_exchange_rate_from_purchase_date`, not `test_bug_4521`. 5. **Fails for the right reason** — after the test, write one sentence predicting the exact failure output (assertion diff or exception). If it would fail with a different error, the repro is wrong. Then add: - **Sibling cases**: 2–3 nearby inputs that probably share the bug (boundary neighbors) — as additional test cases if cheap. - **Root-cause pointer**: one short paragraph on where in the code the defect most likely lives, for whoever writes the fix.