FAQ, answered.

TestCoverNet connects to your repository, either for a one-time onboarding of your main branch or via pull-request webhooks. It generates candidate tests, then deliberately breaks your source code and checks whether each test catches the break. Only tests that catch a real defect are published. Every test we ship arrives with its mutation score attached, as a reviewable pull request.

Line coverage counts which lines executed during a test run. It says nothing about whether a single assertion would notice if the code broke. Mutation scoring measures detection instead: we introduce small deliberate defects into your source, re-run the tests, and count how many defects the tests catch. A test that can't fail isn't coverage, and mutation scoring is what tells the two apart.

That is the failure mode of most generated tests, and it's the reason we gate on mutation scoring rather than on compile-and-pass. A tautological test passes forever and freezes whatever bug was already there. Mutation validation catches the worst of this — a test that asserts nothing meaningful will not kill mutants — but it is not a correctness oracle. Mutation scoring proves a test detects change; it does not prove the behaviour it pins is the behaviour you intended. That judgement stays with your reviewer, which is why everything arrives as a pull request you can reject.

You aren't billed for it, and we tell you. Some code is genuinely hard to generate validated tests for — heavy hidden state, unclear intent, deep coupling. When a file yields nothing above threshold, the run reports the file, the mutants that survived, and why, rather than shipping filler. A report of surviving mutants is more useful than a test that can't fail.

Then we say so and there is nothing to bill. Every run reports your existing suite's mutation score separately from the combined score, so you can see exactly what our tests added — the marginal mutants killed. If that number is zero, your suite is doing its job and you keep your money.

Mutation testing is expensive by nature, so we don't run it across your whole repository on every pull request. Mutation analysis is scoped to the code your diff touches, which ties runtime to the size of the change rather than the size of the codebase. Runs execute on our infrastructure, not your CI minutes, and each run has a compute ceiling — if analysis exceeds it, we report partial results rather than holding your pull request open.

Generated tests are deterministic by construction: no wall-clock time, no unseeded randomness, no live network calls. Tests that need real infrastructure use provisioned database and queue dependencies inside the isolated run environment rather than reaching out to shared services. Any candidate test that produces inconsistent results across repeated runs is discarded before it reaches your pull request.

Unit, internal integration, external integration and system tests, including tests that exercise real database and queue dependencies rather than mocking them away. Every published test is mutation-validated regardless of level.

C# from September 2026, with Rust and Dioxus following in 2027. If you'd like your stack supported, email the team and we'll give you a straight answer rather than a guess.

No. TestCoverNet operates with read-only access to your codebase. Generated tests are proposed as pull requests that your team reviews and merges — nothing lands without your approval, and you can reject any individual test without affecting the rest.

Every test is a liability you have to maintain, so we ship fewer of them rather than more. Tests pin real behaviour instead of snapshotting output, and pull requests are scoped to the change under review rather than dumping a suite across your repository. If a test isn't worth its maintenance cost, reject it — you aren't billed for tests you don't accept.

TestCoverNet integrates with GitHub, GitLab, Gitea and Bitbucket and runs automatically on every pull request, reporting mutation score alongside your existing checks. Always on, with no manual triggering and no changes to your existing pipeline.

A file counts as covered when the tests we deliver for it kill at least 75% of the mutants we generate for that file, and your team accepts the pull request. The threshold is configurable per repository if your standard is higher or lower. If we can't reach the threshold, or you reject the pull request, the file is not billable. You pay for detection you keep, not for files we touched or lines we executed.

For C#, USD $30 per covered file — not per file the pull request touches. Each pull request is capped at 10 billable files by default, so a large refactor can't produce an unforecastable invoice; the cap is adjustable. Monthly ceilings are available for high-change repositories, and volume pricing applies above sustained thresholds. Email us for a quote.

Onboarding is optional and billed per covered file, at USD $80 per file for C#. Before any billable work, we run a free scan of your main branch and give you a per-module yield estimate — how many files we expect to cover and at what score — so you can scope, phase or decline before committing. Onboarding is delivered module by module rather than as one bulk pull request. A 150-file C# service is USD $12,000 at full coverage, but that is a ceiling: you pay only for files that reach threshold and that your team accepts.

Yes. Access is strictly read-only, your code is analysed in isolated, network-restricted environments, and no repository snapshots are retained after a run completes. The service is deployed on major US cloud providers following security best practice.

No. Your code is never used to train AI models. TestCoverNet is built for teams that take code privacy seriously, with read-only access and strict privacy controls, and all generated tests belong to you.