Unit Test Generation Workflow: Coverage for the Code That Changed
Test generation is where AI coding agents earn their keep with the least risk: the output is verified by running it. The workflow watches pull requests, finds the changed functions without tests, generates tests in the repo's conventions, runs them in CI, discards anything that fails or adds no coverage, and opens a companion PR with the survivors for the engineer to review. Coverage goes up on exactly the code that is changing.
Written by Max Zeshut
Founder at Agentmelt · Last updated Sep 11, 2026
The problem
Coverage targets are met by testing easy code and skipping the hard, changed code. Writing tests for someone else's change is the task nobody picks up. Coverage decays on the paths that matter most.
What changes when it runs
Every PR that adds untested logic gets a companion PR with passing tests written in the repo's style, usually within the same hour. Engineers review tests instead of writing them from scratch; coverage on changed code rises; and the tests that survived actually run, because failing ones were never proposed.
Trigger, then 8 steps
Trigger
GitHub / GitLab webhook (pull request opened or updated)
PR events on the main repositories; a label can request generation on demand.
Receive the PR and diff
WebhookChanged files and hunks; PRs from bots or with a skip label are ignored.
Find untested changed functions
CodeCoverage report from CI mapped to the diff: functions and branches that changed and have no covering test.
Assemble context
HTTP RequestThe changed file, its imports, existing test files for the module (for conventions and fixtures), and the test framework config.
Generate tests
AI AgentTests per function in the repo's framework and style, covering the happy path, edge cases visible in the code, and error paths; structured output with one test file per source file.
Run in CI
HTTP RequestGenerated tests pushed to a branch and run with the existing suite; results and the coverage delta collected.
Keep what passes and adds coverage
IFTests that fail are discarded (or retried once with the failure output); tests that pass but add no coverage are dropped; flaky tests (pass/fail on rerun) are dropped.
Open the companion PR
HTTP RequestA PR against the original branch with the surviving tests, a summary of what they cover and the coverage delta, assigned to the original author.
Learn from reviews
Schedule TriggerWeekly: acceptance rate of generated tests, common edits reviewers make, and coverage trend on changed code; prompts adjusted from the edits.
Data it touches
- Git host PR events and repository contents
- CI coverage reports
- Existing test suites (conventions, fixtures)
Guardrails
- Generated tests are proposed in a separate PR; nothing merges without an engineer's review.
- Only tests that pass, are not flaky, and add coverage are proposed — the run is the filter.
- The agent cannot modify source code, only add test files.
- Repositories can be excluded, and a self-hosted model is available for sensitive code.
Verification is built into the loop
The reason test generation is the safest AI coding workflow is that the output is executable. A generated test either passes or it does not; it either raises coverage or it does not. The workflow proposes only tests that did both in CI, which means the engineer reviewing the companion PR is looking at tests that already work. Their job is judging whether the tests assert the right things, not whether they run.
Conventions matter more than cleverness
Tests that ignore the repo's fixtures, naming and structure get rejected regardless of correctness. Feeding the agent the module's existing tests as examples is what makes the generated ones look like they belong. Acceptance rate is the metric to watch; when it drops, the prompt needs better examples, not a bigger model.
Tools in the stack
| Tool | Role in this workflow |
|---|---|
| n8n | PR handling, context assembly, CI orchestration, PR creation |
| Claude | Test generation in the repo's conventions |
| GitHub Actions / GitLab CI | Running tests and coverage |
| Jest / pytest / Go test / JUnit | Test frameworks |
Want this running without building it?
Automation workflow
$247/month
We set up, host and maintain this workflow on n8n and connect it to your tools. Setup included, cancel monthly, you keep the JSON.
Custom build
$3,500–6,000 one-time
Your systems, your rules, your edge cases. A one-off build on Claude and n8n, delivered with documentation and a walkthrough.
Covers up to 500 PRs a month across one organisation with one CI system. Monorepos with custom build graphs, or integration-test generation with fixtures, are a custom build.
Frequently asked questions
Which languages and frameworks?
TypeScript/JavaScript (Jest, Vitest), Python (pytest), Go, Java (JUnit), C# (xUnit) and Ruby (RSpec) out of the box; others as a custom addition.
Will it write tests that just mirror the implementation?
The prompt targets behaviour — inputs, outputs, edge cases, errors — and reviewers reject tautological tests; those rejections feed the weekly prompt review. Coverage delta filtering also drops tests that add nothing.
Is our code sent to a third party?
Changed files and context go to the model provider under your data-processing terms; sensitive repositories can be excluded or served by a self-hosted model.
Case study
AI QA Agent for Fintech Startup: 80% Test Coverage from 35%
How a 30-person fintech startup used AI QA agents to more than double test coverage and ship weekly with confidence.
Calculator
Put your own numbers in
Estimate the cost of the current process and what this workflow changes.
The pillar
AI Coding Agent
Context-aware suggestions, reviews, and refactoring in your IDE—no setup scripts.