Write thorough unit tests for a function

Generate a well-organized test suite covering happy paths, edge cases and failure modes for code you paste in.

Change note: Initial version

Prompt

Write unit tests for the {{language}} code below using {{framework}}.

Code under test:
{{code}}

Behavior notes or requirements (optional): {{requirements}}

Requirements for the tests:
- First list, in plain bullets, the behaviors you will cover, grouped as: normal cases, boundary values, invalid input, and error or exception paths. Add concurrency, time or I/O cases only if the code involves them.
- Then write the full test file. Use descriptive test names that read as sentences about behavior, one logical assertion per test, and a clear arrange / act / assert structure.
- Prefer table-driven or parameterized tests when several cases share a shape.
- Mock only true external boundaries (network, clock, filesystem, database). Do not mock the code under test.
- Do not change the code under test. If you think you found a bug while writing a test, keep the test, mark it clearly, and explain the bug after the file.
- Keep tests deterministic: no real sleeps, no random data without a fixed seed.

After the code, list anything you could not test and why, and note any assumptions you made about intended behavior.

Variables

• {{language}}Languageselect

  Options: TypeScript, JavaScript, Python, Go, Java, C#, Rust, Ruby, PHP, Kotlin, Swift, C++

  Default: Python

• {{framework}}Test frameworktext

  Default: pytest

  e.g. Jest, Vitest, JUnit 5, Go testing

• {{code}}Code to testlongrequired

  Paste the function or class.

• {{requirements}}Behavior noteslong

  Rules the code should follow, if not obvious.

Example output

**Behaviors covered**
- Normal: percentage discount applied, fixed discount applied
- Boundary: discount of 0, discount equal to the price, price of 0.01
- Invalid: negative price, percentage above 100, non-numeric input
- Errors: unknown discount type raises `ValueError`

```python
import pytest
from pricing import apply_discount

@pytest.mark.parametrize("price, kind, value, expected", [
    (100.00, "percent", 10, 90.00),
    (100.00, "fixed", 15, 85.00),
    (100.00, "percent", 0, 100.00),
    (20.00, "fixed", 20, 0.00),
    (0.01, "percent", 50, 0.01),
])
def test_apply_discount_returns_expected_total(price, kind, value, expected):
    assert apply_discount(price, kind, value) == expected

def test_apply_discount_rejects_negative_price():
    with pytest.raises(ValueError):
        apply_discount(-1, "fixed", 5)

def test_apply_discount_rejects_unknown_kind():
    with pytest.raises(ValueError, match="kind"):
        apply_discount(10, "bogus", 5)
```

**Possible bug:** `apply_discount(0.01, "percent", 50)` returns 0.01 because of rounding up; the test documents that and may need a product decision.

**Not tested:** currency conversion, since it lives in another module.

Notes

Listing the behaviors before the code makes the model reason about coverage first. The rule against changing the code under test turns suspected bugs into visible findings.