AI Unit Test Generation Tests for the code that changed, verified by running them
Changed code without tests gets tests written, run in CI, and offered as a companion pull request — only the ones that pass.
- Installed for you · one-time$249
- Run for you$247/month
- Custom build · this process$3,500–6,000 one-time
- Starts whenGitHub / GitLab event (pull request opened or updated)
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. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
AI Unit Test Generation is an automation Agentmelt installs in your own tools. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $247/month, with setup and maintenance included. A custom build of this process is $3,500–6,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-18.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is unit test generation?
AI unit test generation is a workflow that writes tests for the code that changed in a pull request, runs them, and keeps only the ones that pass and add coverage. It reads the diff and the CI coverage report to find the changed functions without tests, assembles the file, its imports and the module’s existing tests (for conventions and fixtures), generates tests in the repo’s framework and style covering the happy path, the visible edge cases and the error paths, and runs them with the suite on a branch. Failing tests are discarded or retried once with the failure output; passing tests that add no coverage are dropped; flaky ones are flagged. The survivors arrive as a companion pull request assigned to the original author, who reviews them like any other.
- Coverage is 40% and every sprint ends with “we will add tests next time”.
- Reviewers ask for tests on every pull request, so tests get written to make the reviewer stop asking.
- The tests we do have mirror the implementation and pass no matter what the code does.
- The one engineer who writes good tests is the bottleneck for everyone else’s merges.
- AI-written tests from the editor plugin get pasted in without ever being run.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
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.
- 16:10 A pull request opens. The coverage report shows which changed functions have no test.
- 16:12 Tests are written in the repo's own framework and style: happy path, visible edge cases, error handling.
- 16:15 They run in CI with the existing suite; failing or redundant tests are discarded.
- 16:20 A companion PR opens with the surviving tests and the coverage delta for the reviewer to accept.
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.
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.
All eight steps run without anyone; a person sees only what the guardrails escalate.
GitHub / GitLab event (pull request opened or updated)
Receive the PR and diff
Changed files and hunks; PRs from bots or with a skip label are ignored.
Find untested changed functions
Coverage report from CI mapped to the diff: functions and branches that changed and have no covering test.
Assemble context
The changed file, its imports, existing test files for the module (for conventions and fixtures), and the test framework config.
Generate tests
Tests 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
Generated tests pushed to a branch and run with the existing suite; results and the coverage delta collected.
Keep what passes and adds coverage
Tests 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
A 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
Weekly: acceptance rate of generated tests, common edits reviewers make, and coverage trend on changed code; prompts adjusted from the edits.
No step waits for a person.
What the workflow hands to someone, by rule:
- Generated tests are proposed in a separate PR; nothing merges without an engineer's review.
Every PR that adds untested logic gets a companion PR with passing tests written in the repo's style, usually within the same hour
Every PR that adds untested logic gets a companion PR with passing tests written in the repo's style, usually within the same hour.
No decisions needed. Anything the guardrails flag is handed to a person; the rest ran alone.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
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.
What it connects to.
| 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?
$247/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$3,500–6,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded 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.
Also sold one-time, installed in your own accounts, as part of the developers package and the engineering teams package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $247/month, setup and maintenance included. Three things move it to a custom build ($3,500–6,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
A monorepo with a custom build graph that decides which tests to generate and run.
Integration tests with fixtures, seeded data or external services rather than unit tests.
Above 500 pull requests a month, or several CI systems.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
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.
Does generative AI write good unit tests?
It writes plausible ones; running them is what makes them good. The rule here is that a test survives only if it passes against the current code, adds coverage the suite did not have, and does not flake across two runs. Tests that restate the implementation are the main failure mode, so the generator works from the function’s contract — its signature, docstring and callers — rather than its body, and the reviewers’ edits are collected weekly to tune the prompts.
Which languages and test frameworks work with AI unit test generation?
Any language with a coverage report CI can produce: TypeScript and JavaScript (Jest, Vitest), Python (pytest), Go (go test), Java and Kotlin (JUnit), C# (xUnit, NUnit), Ruby (RSpec). The workflow reads the framework config and the existing tests in the module, so the generated tests use your fixtures, mocks and naming rather than a generic style.
Is our source code sent to a third party?
The changed file, its direct imports and the module’s tests are sent to the model provider for the generation call under a zero-retention agreement, and nothing else. Repositories that cannot leave your network can run the same workflow against a model hosted in your own cloud account; the CI, the branch and the pull request never leave your version-control system either way.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- GitHub — Actions documentation docs.github.com/en/actions
- Jest — Getting started jestjs.io/docs/getting-started
- pytest — documentation docs.pytest.org/