title: Write Unit Tests

description: Generate focused unit tests for a function, including edge cases.

content:
Write unit tests for this code using {{framework}}:

```
{{code}}
```

Cover: the happy path, boundary values, empty/null inputs, and error conditions. Each test should assert one behavior and have a name that reads as a sentence. Avoid testing implementation details — test observable behavior. List any case you deliberately left out and why.

framework

description: Test framework

code

description: The code under test


title: Edge Case Enumeration

description: Brainstorm the edge cases a piece of functionality must handle.

content:
For this functionality, enumerate the edge cases worth testing: {{functionality}}

Think across categories: empty/zero/one/many, boundaries and off-by-one, null/undefined/missing, very large inputs, duplicates, ordering, concurrency, time zones/locales, encoding, and malformed input. For each, state the expected behavior. Flag any where the correct behavior is genuinely unclear and needs a product decision.

functionality

description: What the code does


title: Test-Driven Development

description: Drive an implementation from tests, red-green-refactor.

content:
Let's build {{feature}} using strict TDD.

Step 1: Write the smallest failing test for the next slice of behavior — stop and show me only the test.
Step 2: After I confirm, write the minimum code to make it pass.
Step 3: Refactor if needed, keeping tests green.

Proceed one cycle at a time. Don't write implementation ahead of a test that demands it.

feature

description: The feature to build


title: Property-Based Tests

description: Design property-based tests that assert invariants over generated inputs.

content:
Design property-based tests for: {{code_or_function}}

Identify the invariants that must hold for ALL valid inputs (e.g. round-trip encode/decode equals identity, output is always sorted, length is preserved). For each property, specify the input generator and any shrinking concerns. Use {{framework}}. Note which properties caught real bugs in your experience with similar code.

description: What to test

framework

description: Property-testing library


title: Increase Test Coverage

description: Find untested branches and add the tests that matter.

content:
Here's code with weak test coverage:

```
{{code}}
```

Identify the branches, conditions, and error paths that aren't exercised. Prioritize them by risk, not by coverage percentage. Write tests for the high-risk gaps first. Explicitly call out any code that doesn't need a test (trivial, generated, or better covered by an integration test).

code

description: The under-tested code


title: Write an Integration Test

description: Test how components work together against real-ish dependencies.

content:
Write an integration test for this flow: {{flow}}

Decide what to use real vs. faked: prefer real for the components under test, fakes/containers for slow or external systems. Cover the success path and at least one realistic failure (timeout, partial write, bad response). Ensure the test sets up and tears down its own state so it's repeatable and isolated.

flow

description: The end-to-end flow to test


title: Diagnose a Flaky Test

description: Find and fix the source of test flakiness.

content:
This test passes sometimes and fails others:

```
{{test}}
```

Identify the source of non-determinism: shared state, timing/sleeps, ordering dependence, real clock, randomness, network, or resource leaks. Propose a fix that makes it deterministic without weakening what it verifies. If the right fix is to make the *code* more testable, say so.

test

description: The flaky test


title: Review Test Quality

description: Critique a test suite for what it actually guarantees.

content:
Review these tests for quality, not quantity:

```
{{tests}}
```

For each test ask: does it test behavior or implementation? Would it fail if the code broke? Would it pass for the wrong reasons? Flag tautological assertions, over-mocking, missing edge cases, and tests that just restate the code. Recommend which to keep, fix, or delete.

tests

description: The test suite to review


title: Write a Test Plan

description: Plan what to test before writing any tests.

content:
I am about to test: {{feature}}

Write a test plan first. List what to verify, grouped by level (unit, integration, e2e), and what NOT to test at each level. Identify the highest-risk areas that deserve the most coverage and the boring parts that need little. Note any test data, fixtures, or environment needed. The goal is confidence per unit of effort, not maximal coverage.

feature

description: What you are testing


title: Mock or Use the Real Thing

description: Decide what to fake in a test and what to keep real.

content:
I am testing {{unit}} which depends on {{dependencies}}.

For each dependency, advise: use the real thing, a fake or stub, or a mock, and why. Keep the thing under test real; fake what is slow, non-deterministic, or external. Warn me where over-mocking would make the test pass while the code is broken (testing the mock, not the behavior). Suggest the minimal test double that still proves the behavior.

unit

description: The unit under test

dependencies

description: Its dependencies


title: Test Error Paths

description: Write tests for the failure cases, not just the happy path.

content:
Here is code whose error handling is untested:

{{code}}

Write tests for the failure modes: invalid input, dependency failures, timeouts, partial writes, and the boundaries where it should reject. Assert the RIGHT failure happens (correct error type and message, no side effects, clean state), not just that it throws. Note any error path that is currently impossible to trigger.

code

description: Code with untested error handling


title: Snapshot vs Assertion

description: Choose the right testing technique for an output.

content:
I want to test this output: {{output}}

Should I use a snapshot test or explicit assertions? Advise based on the nature of the output: snapshots for large stable structures where any change is suspicious; explicit assertions for behavior I can name and that has clear correctness. Warn about snapshot rot (blindly updating). Show what the better choice looks like for my case.

output

description: The output to test


title: Write a Regression Test

description: Lock in a bug fix so it can never silently return.

content:
I just fixed this bug: {{bug}}

Write a regression test that FAILS on the old buggy behavior and PASSES on the fix — so it actually guards the fix. Reproduce the exact condition that triggered the bug, at the lowest level that still captures it. Name the test so a future reader knows what it protects. Confirm it would have caught the original bug, and note any related case worth covering while we are here.

bug

description: The bug you fixed


title: Set Up Test Fixtures

description: Build clean, reusable test setup and data.

content:
My tests for {{subject}} need setup and test data.

Design the fixtures: what to build once versus per-test, how to keep each test isolated (no shared mutable state leaking between them), and how to make the data obvious rather than magic. Prefer builders or factories with sensible defaults over sprawling literals. Keep setup close to the test so a reader sees what matters. Flag any fixture that couples unrelated tests together.

subject

description: What you are testing


title: Test Time-Dependent Code

description: Test logic that depends on clocks, dates, or timeouts.

content:
This code depends on the current time or dates: {{code}}

Make it testable and deterministic. Show how to inject the clock (a time source) instead of calling the system clock directly, so tests can control now, advance it, and freeze it. Cover the tricky cases: timezones, daylight-saving boundaries, leap days, and timeouts. Warn me about tests that secretly depend on real wall-clock time and will flake.

code

description: The time-dependent code


title: Parameterize a Test

description: Turn repetitive tests into one table-driven test.

content:
I have several near-identical tests for: {{behavior}}

Collapse them into one parameterized (table-driven) test: a list of cases, each with inputs and expected output, run through one assertion. Keep each case readable and individually identifiable in the output when it fails. Make sure the cases cover the boundaries, not just the easy middle. Tell me when a case is different enough that it deserves its own named test instead.

behavior

description: The behavior under test