How to Make Your Coding Agent Add Tests First

How do I make my coding agent add tests before I review the PR

Put the test in the task as a required deliverable, not as a suggestion. Tell the agent to identify the behavior change, add or update one test that would fail before the fix and pass after it, run the relevant test command, and report the exact result before it asks for review.

The part people get wrong is asking for “tests” in general. That gives the agent room to add a shallow assertion that touches the same code path without proving the bug is fixed. A proof test has one job: fail on the old behavior and pass on the new one. If the old code already passes, the test does not prove anything.

Use a strict task brief. The agent should finish the test before it explains the code, and the handoff should name the file, the command, and the result. A concise 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 fails before the fix. 3. Make the production 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, name the existing test that already covers the behavior.

Make the review gate enforce the same rule. GitHub protected branches can require passing status checks before merging, and they can also require approving reviews. That means the agent can prepare the PR, but it cannot merge around the test gate if you configure the branch correctly.

The useful habit is to separate creation from approval. The agent creates the proof artifact, then you review the PR only after the test output is visible. GitHub documents that required status checks must pass on the latest commit SHA, so a stale green run from an earlier commit does not satisfy the gate.

For backend changes, ask for the smallest useful test first. That is usually a unit test around the function, service, or boundary that changed. The inconvenient part is that the agent may need to add a seam, dependency injection, or a small refactor before the code is testable. That is a feature, not a detour, because untestable code is hard to trust in review.

For frontend changes, prefer a user path test that exercises the behavior end to end. In practice, that means opening the page, performing the action, and asserting the visible result instead of checking private component state. Those tests take more setup, but they are harder to fake and they prove the thing your reviewer actually cares about.

If you use a code agent inside your own repository, give it a completion rule, not a hope. Say that the task is not done until the test exists and passes. A good prompt is short: “Implement the change, add one test that demonstrates the bug is fixed, run the relevant test command, and return only when the test passes.”

The part that is inconvenient is that some changes need a failing test before the fix is obvious. That is normal. If the agent cannot make the test fail first, it should stop and explain why. Sometimes the behavior is already covered, sometimes the bug is hard to isolate, and sometimes the code path is too broad. In those cases, the agent should name the existing coverage or the missing seam instead of pretending the proof exists.

Use the PR description as a checklist, not a summary. Ask for three sentences: what was broken, what test was added or updated, and what command was run. If the agent claims coverage, check whether the test would have failed on the previous behavior. If it cannot answer that question plainly, the review is not ready.

A practical review pattern is to read the test before the implementation diff. The test tells you what behavior the author thought mattered. If the test is too broad, too mocked, or too coupled to internals, ask for a more direct one before you spend time on the code review. That saves time and cuts down on “looks fine” merges that do not actually protect the bug.

When the agent skips a test, make the reason explicit. A valid skip is “existing test X already covers this behavior,” followed by the exact test name. A weak skip is “I did not think it was necessary.” The second one usually means the agent optimized for a fast-looking PR instead of a defensible one.

If your team wants one line to paste into every task, use this: “No review until there is a failing test for the change, the fix makes it pass, and the PR includes the command used to verify it.” That keeps the instruction concrete, and it matches the branch protection gate you can enforce in GitHub.

DevConnect uses this same basic shape for working with agent-generated changes, and the platform is meant for people building on their own repos, not for bypassing review. You can read the platform at https://devconnectplatform.com and adapt the same shape for your own workflow.

A final check before you review: the PR should answer three questions without extra digging. What changed, what test proves it, and what command verified it. If any of those are missing, send it back before you spend review time on style, naming, or polish.

FAQ

What if the agent adds a test, but it does not fail on the old code Reject it and ask for a better test. A test that passes on both versions is not proof, it is only extra noise in the repository.

Should I require one test or a full suite run Require one focused proof test and, when practical, the narrowest relevant suite. The important part is that the agent shows the exact command it ran, so you can see what was actually verified.

Can branch protection force tests before merge Yes. GitHub protected branches can require status checks before merging, and those checks must pass on the latest commit SHA. That is the enforcement layer that stops a PR from slipping through after the agent hands it back.

What if the change is tiny Tiny changes still need the same proof. The test can be small too, but it still needs to fail before the fix and pass after it.

What is the most common mistake here People ask for “tests” instead of “a test that proves the change.” That wording invites shallow coverage, and shallow coverage does not protect the review.