Generate a pytest suite that tests behavior, not implementation

Write a pytest test suite for the code below. Test the documented behavior and contract, not the internal implementation — if the function's logic were rewritten to do the same thing a different way, these tests should still mostly pass.

CODE UNDER TEST
def parse_discount_code(code: str, cart_total: float) -> DiscountResult: ...

EXTERNAL DEPENDENCIES TO ISOLATE
a database session, an external tax-rate API call. Mock or fake these — do not let the test suite depend on a real network call, real file I/O, or a real database. Use pytest-mock's mocker fixture or unittest.mock.patch, patched at the point of use, not at its original definition.

CURRENT COVERAGE GAP
Nobody has ever tested what happens when the same discount code is applied twice in one cart session.

REQUIREMENTS
1. Use @pytest.mark.parametrize for any case that shares the same assertion shape with different inputs — don't hand-write five near-identical test functions when one parametrized table says the same thing more clearly.
2. Use fixtures for setup shared across tests, and scope each fixture (function, module, session) to the narrowest scope that's still correct — a session-scoped fixture holding mutable state is a bug waiting for test order to change.
3. Cover: the happy path, expired discount codes, codes with leading/trailing whitespace, a valid code where cart_total is below the minimum spend, the gap named in Nobody has ever tested what happens when the same discount code is applied twice in one cart session., and at least one case not listed that you judge worth testing — name why you added it.
4. For anything defined with async def, use pytest-asyncio's async test support — don't wrap async code in asyncio.run() inside a synchronous test.
5. Name each test after the behavior it verifies (e.g. test_returns_empty_list_when_no_matches), not test_1 or test_case_a — a failing test name should tell someone what broke without opening the file.
6. Assert on outcomes and raised exceptions with pytest.raises, never on internal call counts unless the actual requirement is "this must call X exactly once," in which case say so explicitly before asserting it.
7. Every test must be runnable in isolation and in any order — no test may rely on state a different test happened to leave behind, such as a module-level counter or a fixture mutated by an earlier test in the file. If a test genuinely needs a specific order relative to another, say so explicitly and mark it clearly, rather than depending on pytest's default file order by accident and having the suite quietly break the day someone reorders the tests for readability.

OUTPUT FORMAT
1. The test file.
2. A short list of anything you could not test without more context (e.g. a fixture needing real credentials, a race condition that needs a specific timing setup) and why.
3. A one-line map from each test back to the requirement or edge case it covers, so coverage can be checked against expired discount codes, codes with leading/trailing whitespace, a valid code where cart_total is below the minimum spend and Nobody has ever tested what happens when the same discount code is applied twice in one cart session. at a glance rather than trusted on faith.