Quell reads your docstrings, Pydantic models, and type annotations, extracts every testable requirement, finds which ones have no test, generates pytest tests via a rule engine, verifies each test through a 5-gate pipeline, and writes only proven tests to disk.

Does Quell require an LLM API key?

The rule engine runs entirely in-process — no source code is ever transmitted. ~75% of edge cases are handled with no network call and no API key. LLM fallback is opt-in and only sends the function signature, never the full body.

What is the 5-gate pipeline?

Every generated test must pass: Gate 1 (AST valid Python), Gate 2 (not already in a test file), Gate 3 (no shell calls or file writes), Gate 4 (passes against original code), Gate 5 (fails when the requirement is violated). Only gate-5-verified tests are written to disk.

What is the Production Readiness Score (PRS)?

PRS = (WRITTEN × 1.0 + SCAFFOLDED × 0.5) / total_requirements × 100. Tiers: 80-100 Production Ready, 60-79 Review Needed, 0-59 Needs Work.

How is Quell different from GitHub Copilot or Qodo for test generation?

Quell reads specifications that already exist in your code — it does not generate tests from scratch. It finds requirements already documented in your docstrings, Pydantic models, and type annotations that have no test. The 5-gate pipeline, especially Gate 5 (violation injection), verifies each test actually catches the bug it claims to catch. This verification step is not present in Copilot, Qodo, or Hypothesis.

Can Quell be used in CI pipelines?

Yes. Run quell ci src/ --threshold 80 to fail CI if PRS falls below 80. Set prs_threshold in pyproject.toml under [tool.quell]. Works with GitHub Actions, GitLab CI, and any system that checks exit codes.

Can Claude Code or Cursor use Quelltest directly?

Yes. Quelltest ships a local MCP server: install with pip install quelltest[mcp], then add {"mcpServers": {"quelltest": {"command": "quelltest-mcp"}}} to your project's .mcp.json. The agent can then call find_edge_cases, write_verified_tests, get_prs_score, prove_file, and reproduce_bug directly — no terminal needed. A Claude Code plugin is also available via /plugin marketplace add quelltest/quelltest-lib.

Does the Quelltest MCP server send my code anywhere?

No. The local MCP server (quelltest-mcp) runs entirely on your machine over stdio — no cloud, no network calls, no telemetry. The separate opt-in Claude.ai connector only ever transmits sanitized metrics (PRS score, bucket counts, test names, flag locations); a sanitizer blocks source code, function bodies, and docstrings structurally.

How do I add Quelltest as a Claude.ai connector?

In Claude.ai, go to Settings, then Connectors, then Add custom connector, and enter https://mcp.quelltest.com. Claude discovers the OAuth endpoints automatically and walks you through authorization.

What 10 Years of Research Actually Says About Test Coverage

Every CI dashboard I've ever seen has a coverage number on it. Almost none of them have a number for whether the tests would actually catch a bug. That's odd, because the academic literature has been pretty clear for a decade about which of those two numbers deserves your attention. This post is a tour of the evidence — the real papers, what they measured, and what they found — because I think practitioners mostly know coverage is imperfect but underestimate how imperfect.

The paper everyone should read once

The landmark study is Inozemtseva & Holmes, "Coverage Is Not Strongly Correlated with Test Suite Effectiveness" (ICSE 2014). The title is the finding, but the method is what makes it stick.

They took five large open-source Java systems, generated roughly 31,000 test suites of varying sizes from the projects' own tests, and measured two things per suite: coverage (statement, decision, and modified condition) and effectiveness — the fraction of injected faults the suite detected. Then they asked: once you control for suite size, does higher coverage predict higher effectiveness?

The answer: correlation between coverage and effectiveness drops to weak or moderate once suite size is held constant. Bigger suites catch more bugs mostly because they're bigger, not because of the coverage number they achieve. The authors' own conclusion is blunt: coverage is useful for finding under-tested parts of a program, but it should not be used as a quality target.

That last sentence deserves to be framed. Coverage is a decent map of where you haven't looked. It is a poor measure of how well you looked.

But do injected faults even represent real bugs?

Fair objection: those studies inject artificial faults (mutants). Maybe detecting mutants is a game that doesn't transfer to real bugs.

That question got its own major study the same year: Just et al., "Are Mutants a Valid Substitute for Real Faults in Software Testing?" (FSE 2014). Using Defects4J — a curated dataset of 357 real, reproducible bugs from real Java projects — they checked whether test suites that detect mutants also detect the real historical faults.

Result: yes, with caveats. Mutant detection correlated significantly with real-fault detection, independent of coverage; around three-quarters of the real faults were "coupled" to common mutation operators, meaning a test that kills the mutant tends to catch the real bug. The caveated quarter — faults requiring specific environmental conditions or complex state — is real and worth remembering. But as a proxy, "would this test fail if the code were broken?" tracks reality far better than "did this line execute?"

Does any of this survive contact with industry?

Google thought so. Petrović & Ivanković's "State of Mutation Testing at Google" (ICSE-SEIP 2018) describes deploying mutation analysis into the code-review workflow at Google scale. Two design choices matter for practitioners:

Diff-based mutation. They don't mutate the whole codebase; they mutate the changed lines in each review. Verification cost scales with the change, not the repo.
Suppression of unproductive mutants. Not every mutant is worth a developer's attention; they aggressively filter to keep the signal high.

The lesson I take from the Google paper isn't "run mutation testing everywhere." It's that fault-based verification only sticks when it's scoped and cheap — attached to the change you're already making, not a weekend batch job over the whole repo.

The Goodhart problem, quantified

Put the three results together and you get a clean story:

Coverage tells you where tests are missing (Inozemtseva & Holmes).
Fault detection tells you whether tests work (Just et al.).
Fault-based checks are deployable if you keep them scoped (Google).

Now add the incentive layer: the moment coverage becomes a CI gate, it stops measuring what it used to. Teams (and increasingly, AI coding agents) learn to produce tests that execute lines without constraining them — assert result is not None satisfies the gate and verifies nothing. The metric didn't get worse; we optimized against it. Classic Goodhart.

This is why "91% coverage" and "would not survive a flipped boundary condition" happily coexist in the same codebase.

Where this landed for me

I built Quelltest around the research consensus rather than the dashboard consensus. Concretely:

The score we gate on (PRS) counts documented requirements with verified tests, not executed lines.
Every generated test must pass Gate 5: we inject the violation it claims to catch and require the test to fail — the Defects4J-style check, applied per-test, before anything touches disk.
Verification is scoped to the requirement being tested, Google-style, so it runs in seconds inside a normal dev loop.

You can disagree with the tool and still act on the literature: pick one module, break it on purpose, and run your suite. The papers predict what you'll find. The interesting question is what you do the day after.

References: Inozemtseva & Holmes, "Coverage Is Not Strongly Correlated with Test Suite Effectiveness," ICSE 2014 · Just, Jalali, Inozemtseva, Ernst, Holmes & Fraser, "Are Mutants a Valid Substitute for Real Faults in Software Testing?," FSE 2014 · Petrović & Ivanković, "State of Mutation Testing at Google," ICSE-SEIP 2018.