NEWRead
Use case: test generation

AI Test Generation That Actually Runs Green

CodeCourier does not just write test files - it runs them. Each generated test executes in an isolated sandbox and has to pass against your real code before the pull request opens, so you get coverage that proves something, not stubs that compile.

Try CodeCourierHow Issue Sessions work

Coverage that proves nothing

Plenty of tools will generate test files. The problem is what is inside them: assertions that restate the implementation, mocks that mock the thing under test, and suites that pass because they never really exercise the code. Coverage goes up, confidence does not. Worse, untested generated tests can be quietly wrong - green for the wrong reasons - which is more dangerous than no test at all. Real coverage has to run against real code and actually catch a real failure.

How it works

How autonomous test generation works

Step 1

Understand the code

CodeCourier reads the function or module you want covered in an isolated sandbox, maps its branches and edge cases, and identifies the behaviours that actually matter - not just lines to touch.

Step 2

Generate meaningful tests

It writes tests that assert behaviour, cover edge cases and error paths, and follow your existing test conventions and framework through its persona, instead of producing boilerplate.

Step 3

Run them and prove they pass

Every generated test is executed in the sandbox against your real code. Tests that do not run, or that pass for the wrong reason, are caught and reworked before anything is proposed.

Step 4

Open a reviewable PR

CodeCourier opens a pull request with the new tests, the coverage they add, and proof they run green - ready for review, with no stubs slipping through.

Why the sandbox matters

Generating a test is easy; knowing it actually passes is the whole point. The isolated sandbox is where CodeCourier executes every generated test against your real code, with dependencies installed and the suite running, before it proposes anything. That is the difference between coverage you can trust and a file full of green checkmarks that never ran. No test reaches a PR without proving it executes.

More on sandbox isolation

What it does well

  • Unit and integration tests for functions, modules, and APIs
  • Edge cases, error paths, and regression tests around a recent fix
  • Filling coverage gaps in existing suites using your framework and conventions
  • Tests that are executed and proven green before the PR opens

What it will not do

  • It does not inflate a coverage number with tests that assert nothing
  • Flaky, environment-dependent end-to-end suites are out of its safe scope
  • It will not paper over untestable code - it flags what needs a refactor first
  • Generated tests still go through your review before they merge

Representative of how CodeCourier runs as of June 2026. Results depend on your codebase, test coverage, and the scope of the job. CodeCourier escalates to a human when it cannot reproduce or verify a change rather than guessing.

Proof

Generate tests on your own module

Pick a module that is under-tested and point CodeCourier at it. You will get a PR of tests that ran green in a sandbox - judge the assertions, not the count.

Read the issue-to-PR walkthrough
FAQ
How is this different from tools that just generate test files?
The difference is execution. CodeCourier runs every generated test in an isolated sandbox against your real code before it opens a PR, so what you review is proven to run green, not a file that merely compiles. Tests that do not execute, or that pass for the wrong reason, are caught and reworked - you get coverage that actually exercises the code instead of inflating a number.
Will the tests be meaningful or just boilerplate?
CodeCourier targets behaviour: it maps branches, edge cases, and error paths and asserts against them, following your existing test framework and conventions through its persona. It is honest about limits - if code is effectively untestable as written, it flags the refactor rather than generating an assertion that proves nothing. The goal is tests that would catch a real regression.
Can it raise coverage on an existing codebase?
Yes. Point it at under-tested modules and it fills the gaps with tests that run green against your real code, using your framework and style. Because every test is executed in the sandbox first, the coverage you gain is real coverage, not a green wall. You still review and merge, so nothing lands without a human nod unless you have classed it for auto-merge.
Does it run my whole test suite?
When it generates tests it runs them in the sandbox, and it runs the surrounding suite to confirm the new tests pass and nothing else broke. The sandbox has your dependencies installed and your suite available, which is what makes 'it passes' a real claim instead of a guess. If the suite cannot be made green, it reports the blocker instead of opening a PR.

Keep exploring

Bug fixingCode migration
Free for 14 days · no credit card

Hire your first AI engineer.
Ship by lunchtime.

5 minutes to onboard. First PR within an hour. Cancel anytime.

Deploy your first agentBook a 20-min demo