The Best Prompt for Writing Unit Tests

# Task
Write unit tests for the code below using pytest in Python 3.12.

# Code under test
def apply_discount(price: float, percent: float) -> float:
    if price < 0:
        raise ValueError("price must be non-negative")
    discounted = price * (1 - percent / 100)
    return round(discounted, 2)

# Intended behavior
Returns the price reduced by the given percentage, rounded to two decimal places. Raises ValueError for a negative price. The discount is capped at 50 percent: anything above 50 is treated as 50. A discount of 0 returns the price unchanged.

# Dependencies to replace with test doubles
None

# Existing test conventions
Tests in tests/test_pricing.py; use pytest.mark.parametrize for data-driven cases

# Part A - Case inventory (write this first)
Produce a table with the columns: ID, behavior being checked, input or setup, expected result, category. Cover these categories where they apply:
- Typical: the main paths a caller relies on.
- Boundary: empty, zero, one, maximum, first and last element, exact threshold values.
- Invalid input: wrong type, missing field, out-of-range value.
- Error paths: each exception or error return, and failures from each dependency.
- State: repeated calls, ordering, anything that should or should not be mutated.
Leave out cases that only re-test the language or a library. If the intended behavior does not say what should happen for a case, put "UNSPECIFIED" as the expected result and list the question for me instead of inventing an answer.

# Part B - Tests
Write the tests for every case that has a specified expected result.
- One behavior per test. Name each test so that a failure reads as a sentence about the behavior, not about the function name.
- Lay each test out as arrange, act, assert, and keep logic (loops, conditionals) out of test bodies. Use the framework's parameterized form for cases that differ only in data.
- Assert on return values and observable effects. Do not assert on private helpers, internal call order or exact log text unless that is the behavior.
- Replace only the dependencies listed above. Do not mock the code under test or plain data objects.
- Take expected values from the intended behavior, never by copying what the current code would produce. If the code appears to disagree with the intended behavior, still write the test for the intended behavior and mark it with a comment starting SUSPECTED BUG.
- Keep tests deterministic: fix the clock, random seeds and any ordering the code does not guarantee. No real network, file system or database access.
- Use only assertion and mocking functions that exist in pytest. If you are unsure of an API, say so in the notes.

# Part C - Notes
List: suspected bugs with the case ID, unspecified cases as questions, anything in the code that is hard to test and the smallest change that would make it testable, and the command to run the tests.

# Output
Part A as a table, Part B as one fenced code block per test file with the filename above it, Part C as short lists.