You are writing tests for the function below. Framework: [vitest / jest / pytest / …]. Match the style of the example test file I include.
TASK
1. First, list the behaviours the function has, as one-line statements, including edge cases: empty input, null/undefined, boundaries, unicode, very large input, concurrent calls if relevant, and every error path you can see in the code.
2. Mark any behaviour that looks like a bug rather than intent, and say why. Do not write tests that lock in a bug.
3. Then write the tests: one `it`/`test` per behaviour, named as a sentence ("returns an empty list when the input is empty"). Arrange, act, assert. No logic in tests, no shared mutable state between them.
4. Use real values over mocks wherever the function is pure. Mock only I/O.
RULES
- Don't test implementation details (private helpers, call counts) unless I ask.
- If the function's contract is unclear, ask one question instead of guessing.
- Output the behaviour list first, then the test file, nothing else.
FUNCTION
<paste the function and its types here>
EXAMPLE TEST FILE
<paste an existing test file for style>Step 1 is the useful part. Half the time the list shows a case I forgot, and the tests are a bonus.