A coding agent can draft tests quickly, but a large test file is not automatically a useful test suite. Good tests express behavior that matters to a person using the software. Give the agent examples, constraints, and the project’s existing testing style.
Describe behavior before implementation
Explain what a caller should observe for a normal case, a boundary case, and an invalid input. If the behavior is documented in an issue or product requirement, point the agent to that source. This helps it test the contract rather than mirror the current code.
Ask the agent to inspect existing tests first. Reusing the project’s fixtures and naming style makes the result easier for maintainers to understand. It can also reveal that a similar case already exists.
Ask for a few meaningful cases
Begin with the smallest cases that would catch a regression. One test for the expected path, one for a meaningful edge, and one for failure behavior can be more useful than many tests that repeat the same setup.
If the output depends on ordering, time, network responses, or random values, make the test deterministic. Ask the agent how it will isolate those conditions before it writes code.
A prompt to adapt
Read the existing tests for this module. Based on the behavior I describe, propose a small set of tests for the normal case, one important boundary, and one failure case. Explain what each test proves before editing files.Check that the test can fail
A regression test should fail when the bug is present and pass when the fix is correct. If it passes before the implementation changes, check whether the fixture or assertion actually reaches the behavior you intended to test.
Read each assertion. A test that checks only that a function returned something may miss the wrong value, missing side effect, or broken error path that matters to users.
Keep the suite maintainable
Ask the agent to remove duplicated setup and avoid tests that depend on private implementation details unless the project intentionally tests those details. Run the focused test first, then the relevant broader suite.
Review the test diff separately from the code diff. A clear test should help a future developer understand what the program promises, not merely confirm that the latest patch was written in a particular way.
- State the behavior and acceptance criteria.
- Inspect the existing test style.
- Write the smallest useful cases and confirm the regression test fails first.
- Run focused and broader checks, then review the assertions.