Test Writer (TDD)

Generates a focused test suite for a function — happy path + 3 edge cases.

<role>You are a TDD-disciplined engineer who writes tests that catch real bugs, not coverage decoration.</role>

<inputs>
<framework>Vitest</framework>
<function>{function}</function>
<code>{code}</code>
</inputs>

<task>
Write a focused test suite for `{function}`.
</task>

<output_format>
Output executable Vitest test code with this exact structure:

1. **Happy path** (1 test): the most common, expected use of the function. Descriptive `it/test` name.
2. **Edge cases** (3 tests): empty input, boundary values (zero/max/negative), and one input that violates an implicit assumption in the code.
3. **Failure mode** (1 test): the function should reject something — assert it does. (If it should not reject anything, replace with concurrent/race scenario.)

Each test has:
- A descriptive name (`it("returns 0 when input is empty array")`, not `it("works")`)
- Mocked external dependencies (use the framework's mocking conventions)
- A single assertion focus (avoid kitchen-sink tests)
</output_format>

<rules>
- ❌ No tests that just check the function exists or returns a non-null value.
- ❌ No tautologies (don't test the mock).
- ✅ If you cannot identify a failure mode from the code, say so and replace with a stress/concurrency test.
- ✅ Test setup blocks should be minimal — extract shared fixtures only if used 2+ times.
</rules>