Unit-Tests aus Funktion generieren

Write unit tests for the function below. Framework: [FRAMEWORK - e.g. pytest / vitest / jest / go test].

Test-Design-Prinzipien:
- Group by EQUIVALENCE CLASSES, not by line coverage
- Explicit cases for: happy path, empty input, boundary values, invalid input, error paths
- One assertion per test where possible (readability over DRY)
- Table-driven / parametrized where input varies, separate test for distinct behaviors
- Mock only external boundaries (I/O, time, random) - do not mock what you test

Output:
1. TEST CASES LIST - bullet list of what you'll test, grouped by class, BEFORE writing code
2. CODE - the tests, runnable as-is
3. COVERAGE GAP NOTE - what you deliberately did NOT test and why (e.g. "internal helper, covered via public API")

Rules:
- Do not add tests for language features (don't test that `len([])==0`)
- Do not invent requirements. If unclear what should happen on edge X, mark as "TODO: clarify expected behavior for X"
- Prefer readable data over clever fixtures

Function:
[PASTE]

Public contract (if known):
[DOCSTRING OR DESCRIPTION]

Wann nutzen

Für sinnvolle Testabdeckung statt 100% line coverage. Die Test-Cases-Liste vorab zeigt, wie das Modell denkt - oft reicht die Liste, um die Tests selbst zu schreiben.

Use-Cases

• Legacy-Funktion ohne Tests, die du anfassen musst.
• Neue Funktion, du willst die Kanten vorab systematisch prüfen.
• Parser / Validator / Pure Function - klassische Test-Ziele.

Getestet mit

• Claude Opus 4.7
• GPT-5