Testing & Debugging with AI

A unit test targets one method in isolation. Copilot Chat’s /tests slash command generates a test suite for the file open in the editor, and reading an existing test file in an adjacent tab helps it match the project’s conventions; Claude Code takes the same request as an ordinary prompt with an @ reference.

See GitHub — Writing tests with GitHub Copilot and Claude Code — Best practices, whose specificity table makes the same "name the file, the case, the convention to match" point.

An integration test exercises more of the stack together — here, the full Spring context, the repository and the ranking logic behind /api/pages/{id}/related. Breaking the request into the specific cases to cover, rather than asking for "integration tests" generically, is what keeps the assistant’s output matched to what the endpoint actually does:

This is the same three-case list Prompting Coding Assistants's "Tests" phase already specifies for the related endpoint; repeating the exact cases here keeps this page’s example directly runnable against the same test class.

Edge cases are the inputs a hand-written happy-path test tends to skip: a limit of 0 or a negative number, an id that isn’t a valid Long (/api/pages/abc/related), and a candidate list that is empty before ranking starts. Naming them explicitly, instead of asking for "more tests", is what actually produces them:

Where a unit test checks one input/output pair, a property-based test states an invariant that must hold for every generated input and lets the framework search for a counterexample. jqwik (net.jqwik:jqwik, the current test engine for the JUnit 5 platform) generates the inputs for a @Property method’s @ForAll parameters; a @Provide-annotated method can build a custom Arbitrary when the parameter type is a project class rather than a plain number or string. The property below states two invariants of the ranking helper behind DocsController.related — that it never returns more than the requested limit, and that its output stays sorted by descending score:

A prompt to generate this asks the assistant for the invariant, not the test code directly, since the invariant is the part a human still has to get right:

Hypothesis is jqwik’s Python counterpart, used here on the ranking logic inside ingest/build_index.py. Its @given decorator plays the same role as jqwik’s @ForAll, drawing from strategies (imported as st):

See jqwik — User guide and Hypothesis — Quickstart.

Fuzz testing pushes the same generate-and-check idea toward large volumes of adversarial or malformed input, specifically looking for crashes rather than checking a business invariant. Both frameworks above double as fuzz tools once the generator targets input shapes an attacker or a malformed request might send instead of only well-formed domain objects — an oversized or negative limit, a scores list with NaN or infinite values, or a raw string in place of a numeric id:

When a generated case fails, both frameworks shrink it automatically to the smallest input that still reproduces the failure, which is what makes the reported counterexample directly usable when feeding it back to the assistant, as in "Test-driven debugging" below, rather than a large hard-to-read fixture.

Asking an assistant to review a test file it did not just write catches gaps a human skimming the same file tends to miss — an untested branch, a missing negative case, an assertion that would still pass if the implementation were wrong:

See GitHub — Writing tests with GitHub Copilot, which documents this same "what additional tests should be included" pattern.

A failing test is a check the assistant can run and read the result of on its own, which turns a session you have to watch into one that closes its own loop: the assistant edits code, re-runs the test, reads whether it passed, and repeats until it does, or until it runs out of ideas and reports back. Without that check, "looks done" is the only signal available, and a human has to supply the verification step every time instead. This is why the earlier prompts above all end with "re-run the test" rather than stopping at the code change.

For an unattended run — one nobody is watching turn by turn — the same idea can be enforced rather than merely asked for: Claude Code’s Stop hook runs a script every time the assistant is about to finish responding and can block that stop, forcing another turn, until the script it runs (typically the project’s test command) exits successfully. A minimal version in the project’s .claude/settings.json points the Stop event at a script:

The script runs mvn -q test -Dtest=DocsControllerTest and exits 0 when it passes, or exits 2 with the failure on stderr when it doesn’t. Exit code 2 blocks the stop and hands that stderr text to Claude as the reason to keep working. The hook input’s stop_hook_active field is true when Claude is already continuing because of a stop hook, and as of 2026-09-28 Claude Code overrides the block after eight consecutive continuations, so a test that can never pass doesn’t loop forever. See Claude Code — Hooks reference (Stop) and Claude Code — Best practices ("Give Claude a way to verify its work"). Authoring hooks in depth is covered in Hooks; this page only shows the mechanism as the deterministic version of "tests as the success criterion" above.

Before fixing a reported bug, ask the assistant to turn the report into a failing test first — proving the bug exists and giving both of you a concrete check for "fixed" that doesn’t depend on re-reading the original report:

This is the same "write a failing test that reproduces the issue, then fix it" pattern Claude Code — Best practices recommends for describing a symptom, applied here specifically to reproduction rather than to fixing a build error.