Write unit tests that cover the edge cases
Generates a test suite for a function or class, including the boundaries and failure paths people forget, and lists any bugs it noticed along the way.
Write unit tests for the code below.
Language and test framework: {{framework}}
Before writing any tests, list the behaviors worth testing, grouped as:
- Normal cases: typical valid input.
- Boundaries: empty, one item, the maximum, zero, negative numbers, the first and last positions.
- Invalid input: wrong type, missing fields, malformed data.
- Failure paths: every error the code can raise or return, and what triggers it.
Then write the tests.
- One behavior per test. Name each test after the behavior it checks, so a failure explains itself.
- Arrange, act, assert, with a blank line between each part.
- Check results, not implementation details. Do not test private helpers directly.
- Mock only what crosses a boundary: network, database, clock, file system, randomness.
- Each test must be able to run alone and in any order.
Rules:
- Match the conventions of the framework I named.
- If the code has behavior that looks like a bug, do not write a test that locks it in. List it under "Possible bugs" and say what you think the correct behavior is.
- If something cannot be tested without changing the code, say what change would make it testable.
Code:
{{code}}Hannah Lindgren · Coding