Coding Workflows Workflow Intermediate

AI Test Generation Workflow

Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.

The problem

Ask an AI to write tests for a file and you get a wall of assertions that cover the happy path and little else — they pass, they look thorough, and they'd miss the bug that actually ships. Tests only earn their maintenance cost if they fail when something is genuinely wrong. That takes understanding the behavior before writing assertions, building coverage in the right layers, and deliberately hunting the edges instead of restating the obvious.

Recommended workflow

Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.

  1. Pin down the behavior worth testing

    Get the AI to state, in plain terms, what the code is supposed to do — the rules, the inputs that matter, the outputs that count. Assertions written without this just freeze whatever the code currently happens to do.

    Goal A clear statement of intended behavior to write tests against.

    Open this step in Code Explanation Prompt
  2. Cover the core with unit tests

    Start where bugs are cheapest to catch: isolated unit tests for the core logic, one behavior per test, fast to run.

    Goal Unit tests that pin the core logic and fail loudly when it breaks.

    Open this step in Test Case Prompt Generator
  3. Test the seams with integration tests

    Unit tests miss the wiring. Add integration coverage — and end-to-end where it earns its keep — for the boundaries: the database call, the API contract, the place two modules meet.

    Goal Coverage where components actually connect, not just inside them.

    Open this step in Test Case Prompt Generator
  4. Hunt the edges

    Bugs live at the boundaries: empty, huge, duplicate, concurrent, malformed. Have the AI enumerate the edge and failure cases the happy-path tests skipped.

    Goal Tests for the inputs that break things, not just the ones that work.

    Open this step in Test Case Prompt Generator
  5. Review the suite for blind spots

    Turn the review lens on the tests themselves: what behavior is still uncovered, which tests assert nothing useful, and where a passing test gives false confidence.

    Goal A suite with its gaps named — and a short list of what to add.

    Open this step in Code Review Prompt Generator

Expected outcome

A layered test suite — unit, integration, edge — written against stated behavior and reviewed for gaps. The tests fail when something is genuinely wrong, which is the only property that makes them worth keeping.

Best for

  • Adding coverage to code that has little or none
  • Turning a vague 'write tests' into a real suite
  • Backfilling tests before a refactor or release

Not for

  • Pinning a single bug — the AI Debugging Workflow's test step is enough
  • Code whose behavior you can't yet describe — understand it first

FAQ

How is this different from a unit test prompt?

A test prompt generates one kind of test for code you paste in. This workflow decides what's worth testing first, builds coverage across unit, integration, and edge layers, then reviews the result for gaps — so the suite is meaningful, not just large.

Why understand the code before writing tests?

Tests written without knowing the intended behavior just freeze whatever the code does now, bugs included. Stating the intended behavior first means a failing test signals a real problem, not a deliberate choice.

Do I need the integration and edge steps every time?

Skip what doesn't apply. Pure logic might only need units and edges; a module full of I/O leans on integration. The review step is the one to always keep — it's what tells you what you missed.

Tip: Each step's resource opens its tool pre-filled — start at step one and carry the output forward.

All playbooks