22  Spell of Test Generation

23 Spell of Test Generation

Working seal: spell://test-generation/16A7DCF9E2

Use when: Use when behavior needs focused tests and edge-case coverage.

23.1 Copyable Template

Raw template: prompts/spells/test-generation.txt

ROLE:
Act as a meticulous test engineer.

OBJECTIVE:
Generate a focused test suite for the supplied function or module that captures intended behavior and important edge cases.

CONTEXT:
The code may be partially undocumented. Existing examples, docstrings, and type hints are the primary clues to behavior.

CONSTRAINTS:
Prefer high-signal tests over high-count tests. Group tests by behavior. Avoid mocking unless interaction boundaries require it.

Call out assumptions whenever behavior is not explicit.

PROCEDURE:
Infer invariants, enumerate edge cases, identify boundary values, and generate tests that make hidden assumptions visible.

OUTPUT CONTRACT:
Return:

1\. inferred behaviors,

2\. missing-behavior ambiguities,

3\. the test file,

4\. a short rationale for each test group.

VERIFICATION:
Include nominal cases, boundary cases, error cases, and one regression-style case if appropriate.

FAILURE BEHAVIOR:
If the code is too ambiguous for faithful tests, write characterization tests and say that you are doing so.

23.2 Related Runes

• 1152 contract test - A promise checked at the seam between systems. Use it when mocks are too flattering and end-to-end tests are too blunt.
• 1186 property-based test - Instead of checking one remembered example, ask whether a law survives many generated cases. Use it when you care more about the invariant than the anecdote.
• 1172 invariant - A law that must remain true while the rest of the system is allowed to move. If you cannot say the invariant, you probably do not yet understand the change.
• 1485 reproducible - Can be rebuilt or rerun and yield the same result again.
• 1445 deterministic - Given the same inputs, the same result should return. This is the antidote to drift, heisenbugs, and unreviewable behavior.

23.3 Related Pages

• Canonical Spell Skeleton
• Cast Levels
• Failure Modes
• Canon Map
• Proof by Difference Case
• Recorded Evaluations

23.4 Source Form

23.5 Spell of Test Generation

ROLE:

Act as a meticulous test engineer.

OBJECTIVE:

Generate a focused test suite for the supplied function or module that captures intended behavior and important edge cases.

CONTEXT:

The code may be partially undocumented. Existing examples, docstrings, and type hints are the primary clues to behavior.

CONSTRAINTS:

Prefer high-signal tests over high-count tests. Group tests by behavior. Avoid mocking unless interaction boundaries require it.

Call out assumptions whenever behavior is not explicit.

PROCEDURE:

Infer invariants, enumerate edge cases, identify boundary values, and generate tests that make hidden assumptions visible.

OUTPUT CONTRACT:

Return:

1. inferred behaviors,

2. missing-behavior ambiguities,

3. the test file,

4. a short rationale for each test group.

VERIFICATION:

Include nominal cases, boundary cases, error cases, and one regression-style case if appropriate.

FAILURE BEHAVIOR:

If the code is too ambiguous for faithful tests, write characterization tests and say that you are doing so.