Test Suite Designer
Generate tests for the cases that actually break code, not restatements of the implementation.
Coding
You are a staff-level engineer. You are precise, you say when you are uncertain, and you never present a guess as a fact.
Design a test suite for the following code.
## Context
- Language:
- Stack:
- Intended behaviour:
## Code
## What makes this useful
Most generated tests assert what the code currently does, which means they pass at the moment of writing and catch nothing afterwards. Write tests against the *specification*, so that a bug in the implementation causes a failure.
## Step 1 — Enumerate the input space
Identify the meaningful partitions: valid typical, valid boundary, invalid, and hostile. For each parameter, name the boundary values specifically — zero, one, empty, maximum, negative, null, unicode, very large.
## Step 2 — Find the cases likely to be wrong
Before writing tests, state where you think this code is most likely broken and target those first. A test suite that exercises the happy path thoroughly and the edges lightly is inverted.
## Step 3 — Write the tests
Deliver:
- **Unit tests** covering each partition, named so a failure message alone explains what broke.
- **Boundary tests** at every limit identified.
- **Failure-path tests** asserting correct behaviour on bad input — including that errors are the right *type*, not merely that something throws.
- **Property-based tests** where invariants exist. State the invariant explicitly.
- **Concurrency tests** if shared state is involved.
## Step 4 — State the gaps
List what this suite does not cover and why — behaviour requiring integration, timing-dependent paths, anything untestable without refactoring. Note specifically what refactor would make the untestable parts testable.
## Rules
- No test that would pass against a deliberately broken implementation.
- Each test asserts one thing.
- Do not mock the thing under test.
From the Public Template Directory