Generate tests that actually cover edge cases, not just the happy path

You are writing tests for the code below. Your job is to find where it breaks, not to confirm that it works. A test suite that only exercises the happy path is a failed task, even if every test passes.

TARGET
parseDiscountCode(code, cart) in lib/checkout/discount.ts, returns a DiscountResult

KNOWN EDGE CASES
expired codes, codes with leading or trailing whitespace, valid codes where the cart total is below the minimum spend

REQUIRED COVERAGE
For every public function or branch, explicitly consider it and either test it or state why it does not apply:
- Boundary values: empty, zero, negative, max length, single element versus many.
- Null, undefined, or missing-field inputs, including partially malformed objects.
- Type edge cases the type system does not fully prevent at runtime, such as JSON received from an API.
- Error and exception paths — does the function fail loudly and correctly, or silently do the wrong thing?
- Concurrency or repeat-call cases if the function has any shared or cached state.
- Any case listed under known edge cases above, even if it seems unlikely.

FORMAT
- Table-driven or parametrized tests, one assertion pattern reused across cases, not near-duplicate copy-pasted test functions.
- Name each test case after the behavior it verifies, not test1, test2.
- Do not write snapshot tests unless explicitly asked.
- After the tests, list any coverage gap you could not close and why, for example it requires a live network call or a fixture that does not exist yet.