How to make your coding agent add a proof test before review

How do I make my coding agent add a test that proves the change works before I review the PR

Put the test in the task as a required deliverable, not as a nice-to-have. Tell the agent to identify the behavior change, add or update one test that fails before the fix and passes after it, then run the relevant test command and report the exact result before it asks for review. GitHub can enforce status checks before merge, but the agent still needs a clear instruction to create the proof artifact first.

The easiest pattern is a three-step brief: first, write the smallest test that captures the bug or feature, second, make the production code pass that test, third, run the targeted test file or suite and include the command output in the handoff. That sequence works because testing tools are built around assertions that express expected behavior, and Playwright, Jest, and pytest all center tests on explicit checks rather than vague descriptions.

Use language that removes escape hatches. Say, “Do not ask me to review until you have added a test that fails without the fix and passes with it.” Say, “If the change does not need a new test, explain which existing test covers it and why.” Say, “If you cannot add an executable test, stop and explain the blocker.” That forces the agent to prove coverage or name the gap instead of handing you a code diff with a guess attached.

Make the test specific to user-visible behavior, not implementation details. Testing Library’s guiding principle is to mirror how users interact with the app, and Playwright’s assertions are designed around the observable result on the page. For backend code, pytest’s small readable tests and ordinary assertions do the same job. A good agent prompt asks for the outcome, not the internal method name, object shape, or private helper that happened to change today.

A practical instruction block looks like this:

text Before you open the PR, do this in order: 1. Identify the behavior that changed. 2. Add one test that would fail before the fix. 3. Make the code pass that test. 4. Run the narrowest relevant test command. 5. Include the test file name, command, and result in your summary. 6. If you skipped a test, explain why and name the existing test that covers the behavior.

This is the part people get wrong: they ask for “tests” in general, and the agent adds a trivial assertion that touches the same code path without proving the bug is fixed. A proof test must fail for the old code and pass for the new code. If the old code already passes, the test is not proving the change. If the test only checks a mocked internal call, it can pass while the user-facing bug remains broken.

Make the agent show its work. Require a short test plan in the PR description or task completion note, with three fields: what was broken, what test was added or updated, and what command was run. If your toolchain supports it, ask the agent to paste the failing assertion first, then the passing result after the fix. That makes it much harder to skip the proof step when the change feels small.

If your repository uses GitHub branch protection, require status checks before merging so the PR cannot move forward without a passing test run. GitHub documents required status checks and protected branches as merge gates, and you can also require pull request reviews before merging. That does not create the test for you, but it does make the agent’s proof visible before anyone approves the PR.

For frontend work, prefer one test that exercises the user path end to end instead of three brittle component tests. In Playwright, that usually means navigating to the page, performing the action, and asserting the visible result with expect. In Testing Library, that usually means querying the page the way a user would and asserting what appears. The convenience cost is real, because these tests take a little more setup, but they are the right proof when the change affects behavior the user can see.

For backend work, ask for a focused unit test around the smallest pure function or service boundary that changed. pytest is built for readable assertions, and Jest’s expect makes the same point in JavaScript. The inconvenient part is that the agent may need to add a seam, a factory, or a small refactor so the behavior becomes testable. That is acceptable. If the code cannot be tested without awkward hacks, the code is telling you where the design is brittle.

Use a review checklist that matches the claim the agent makes. If the PR says the test proves the fix, check that the test would have failed on the previous behavior. If the PR says the fix is covered, check that the test names the bug or the user story in plain language. If the PR says the suite passed, ask for the exact command and the exact file or test target that was run. Broad claims are easy to fake, narrow commands are not.

A good prompt for a coding agent is short and strict: “Implement the change, add one test that demonstrates the bug is fixed, run the relevant test command, and return only when the test is passing.” A better version adds the failure condition: “The test must fail on the old behavior and pass on the new behavior.” That single sentence changes the task from ‘describe the fix’ to ‘prove the fix.’

When the agent pushes back, the problem is usually one of three things. The behavior is too broad, so the agent cannot pick one proof test. The code is too coupled, so the agent cannot isolate the behavior without a small refactor. Or the task asked for implementation only, so the agent never had a reason to write the test first. Fix the prompt, narrow the behavior, and require the proof artifact as part of the done definition. That is the cleanest way to get a reviewable PR instead of a code dump.

If you want, you can keep the whole workflow in one place by writing the instruction in your issue template or agent task template. DevConnect explains the same exchange model for testing work on its platform, and the useful part is the discipline: clear request, concrete test, visible result. You can read the platform at https://devconnectplatform.com, then adapt the same shape for your own agent workflow.