Unit tests for a Python function or module

You are a test engineer. Write unit tests for the code below that describe its intended behavior, not just whatever it happens to do today. Inputs - Code under test: {{code}} - Intended behavior in plain words: {{intended_behavior}} - Test framework to use: {{test_framework}} - Things that must be replaced with fakes (network, files, clock, database): {{external_dependencies}} Steps 1. Summarize the intended behavior as a short list of rules. If the code and the stated behavior disagree, say so and ask up to 3 questions; otherwise proceed. 2. List test cases in four groups: normal cases, boundary cases (empty, zero, one, maximum), invalid input, and failure of dependencies. 3. Write the tests. One behavior per test, names that read like sentences, arrange-act-assert layout, no logic inside tests, no dependence on test order. 4. Use fakes for every dependency listed. Do not touch the real network, disk or clock. 5. Map each rule from step 1 to the tests that cover it and name any branch you could not cover and why. Output format - Rules extracted (bullets) - Test plan table: Test name | Group | Rule covered - Test code in one block, ready to run - Coverage gaps and suggested follow-ups Quality bar - Expected values must come from the stated behavior, not copied from running the code. - If the code has a likely bug, write a test that exposes it and mark it clearly instead of making it pass. - No random data without a fixed seed. - Keep the file self-contained and short; do not add helper frameworks.

You are a test engineer. Write unit tests for the code below that describe its intended behavior, not just whatever it happens to do today. Inputs - Code under test: {{code}} - Intended behavior in plain words: {{intended_behavior}} - Test framework to use: {{test_framework}} - Things that must be replaced with fakes (network, files, clock, database): {{external_dependencies}} Steps 1. Summarize the intended behavior as a short list of rules. If the code and the stated behavior disagree, say so and ask up to 3 questions; otherwise proceed. 2. List test cases in four groups: normal cases, boundary cases (empty, zero, one, maximum), invalid input, and failure of dependencies. 3. Write the tests. One behavior per test, names that read like sentences, arrange-act-assert layout, no logic inside tests, no dependence on test order. 4. Use fakes for every dependency listed. Do not touch the real network, disk or clock. 5. Map each rule from step 1 to the tests that cover it and name any branch you could not cover and why. Output format - Rules extracted (bullets) - Test plan table: Test name | Group | Rule covered - Test code in one block, ready to run - Coverage gaps and suggested follow-ups Quality bar - Expected values must come from the stated behavior, not copied from running the code. - If the code has a likely bug, write a test that exposes it and mark it clearly instead of making it pass. - No random data without a fixed seed. - Keep the file self-contained and short; do not add helper frameworks.

Rules extracted 1. apply_discount(price, percent) returns price reduced by percent. 2. Percent below 0 or above 100 is rejected. 3. Result is rounded to 2 decimals. Test plan | Test name | Group | Rule | | test_ten_percent_off_100_returns_90 | Normal | 1 | | test_zero_percent_returns_original_price | Boundary | 1 | | test_negative_percent_raises_value_error | Invalid | 2 | | test_result_rounds_to_two_decimals | Boundary | 3 | Test code: (block with the four tests) Coverage gaps: behavior for a negative price is not specified; please confirm the intended result.