CovQValue for Curiosity-Driven Test Generation

• CovQValue is a curiosity-driven planning method that treats test generation as a sequential decision-making process using coverage maps to estimate branch reachability.
• It generates diverse multi-step test plans scored by combining immediate branch discovery with a future reachability term, overcoming limitations of greedy approaches.
• Empirical evaluations show CovQValue achieves up to 77% higher branch coverage on real Python modules compared to reactive test generation methods.

Searching arXiv for the CovQValue paper and closely related context papers to ground the article. CovQValue is a curiosity-driven planning method for iterative, LLM-based unit test generation for real Python code. It treats test generation as sequential decision-making in an unknown environment, uses a coverage map as a proxy probabilistic posterior over the program’s branch reachability structure, generates diverse multi-step test plans, and ranks them by an LLM-estimated curiosity Q-value that combines immediate branch discovery with future reachability. In the reported experiments, this planning-based formulation is designed to overcome “coverage corridors,” namely sequences of setup steps that each contribute zero new branch coverage individually, but collectively unlock access to deep logic (Amayuelas et al., 6 Apr 2026).

1. Definition and problem setting

CovQValue is introduced in a setting where an agent interacts with a target Python module or file $P$ in a real repository. The agent can inspect the source of $P$, generate test scripts that import and call into $P$, and execute those scripts in an instrumented environment that reports which branches were executed. The objective is to maximize cumulative branch coverage over a fixed execution budget $N$, with branch coverage defined as the number or fraction of distinct control-flow branches in the target module that have been taken at least once.

The method is motivated by a limitation of existing LLM-based test generation tools such as CodaMosa, CoverUp, and TestForge. These systems typically optimize each step for immediate coverage gain. The paper argues that this greedy regime plateaus on code with “coverage corridors,” because any single setup step in such a corridor appears uninformative in isolation. The examples given include multi-step initialization sequences in frameworks, validation gates, and import chains and configuration requirements. In these regimes, a selector that always chooses the test predicted to maximize immediate coverage will not invest in a sequence of zero-gain steps and therefore will not reach the deep branches behind the corridor (Amayuelas et al., 6 Apr 2026).

The formal reframing is explicitly Bayesian. The unknown environment parameter $\Theta$ is the program’s full branch reachability structure. At step $t$, the agent takes an action $a_t$, observes an outcome $o_t$, and accumulates a history

$h_t = (a_1,o_1)\dots(a_t,o_t).$

The exploration objective is to maximize cumulative information gain about $\Theta$, approximated in this application by the total number of distinct branches discovered.

2. Bayesian exploration formulation

The method maps the components of optimal Bayesian exploration onto iterative test generation. In the paper’s formulation, the prior $P$0 corresponds to initially having no observed branches, the history is the sequence of test-plan and coverage-result pairs, and the posterior exploration state $P$1 is approximated by a coverage map $P$2. The action is a test plan, defined as a sequence of $P$3 scripts, and the observation is the set of branches hit by executing that plan.

The theoretical quantities are written as

$P$4

for expected information gain and

$P$5

with $P$6, for the curiosity Q-value. CovQValue does not compute this posterior or mutual information explicitly. Instead, it uses a deterministic coverage map as a sufficient statistic for exploration and relies on the LLM to perform implicit Bayesian reasoning conditioned on that map (Amayuelas et al., 6 Apr 2026).

The coverage map is cumulative: $P$7 and the implementation updates it after each execution via

$P$8

In prompts, the map is serialized as structured text. The examples in the paper include fields for total branches discovered so far, the number of new branches from the last step, average gain per step, a ranked list of the most informative tests with branch counts, and warnings when coverage has stagnated for several steps. This makes the exploration state legible to the model without constructing an explicit probabilistic posterior.

A recurrent misconception is to read this formulation as conventional Bayesian RL with an explicit posterior update. The paper states the opposite: the precise distribution $P$9 is never computed, and the Q-values are heuristic plan-ranking signals rather than Bellman-consistent value estimates.

3. Algorithmic structure

CovQValue is an iterative open-loop planner. At each planning round it maintains a coverage map $P$0 and a history $P$1, generates $P$2 diverse candidate multi-step plans, asks the LLM to estimate for each plan an immediate expected gain $P$3 and a future reachability term $P$4, computes

$P$5

and executes the plan with the highest $P$6, step by step, updating $P$7 and $P$8 after each script execution.

Using the notation given in the paper, the plan set is

$P$9

where $N$0 is the script at step $N$1 of plan $N$2. The formal loop initializes $N$3 and $N$4, generates $N$5 plans with diversity hints, scores them by curiosity Q-value, selects

$N$6

and then executes $N$7 sequentially until the total execution budget is exhausted (Amayuelas et al., 6 Apr 2026).

The main experiments use $N$8 steps per plan and $N$9 plans per round. With total budget $\Theta$0 scripts, this yields $\Theta$1 rounds of planning. The plan structure is explicitly intended to support corridors: step $\Theta$2 can be basic setup, step $\Theta$3 can build on that setup, and step $\Theta$4 can probe deeper logic or edge cases that only became reachable after the earlier steps.

The scoring rule is deliberately simple. For each plan, the LLM is asked for two numbers: immediate gain, interpreted as the number of total new branches expected from the plan, and future value, interpreted as the number of additional branches that become reachable by future tests after this plan. The absolute scale is not the important quantity; only the induced ranking over candidate plans matters.

4. Prompting, execution loop, and implementation details

Every generation and scoring prompt contains three pieces of state: truncated source code of the module, the current coverage map, and a short test history listing prior tests and their branch contributions. For plan generation, the prompt asks for “a sequence of 3 test scripts that TOGETHER will reach UNCOVERED code paths” and includes directional guidance such as “MAIN functionality,” “ERROR HANDLING,” or “INTERACTIONS.” These directives are used as diversity hints so that the $\Theta$5 plans per round explore different parts of the reachable behavior.

For plan scoring, the prompt presents the same module context and coverage map together with a single proposed plan and asks the model to output two integers in the format “immediate, future.” The orchestrator then computes the scalar score $\Theta$6. In the main experiments, $\Theta$7, and ablations consider $\Theta$8 (Amayuelas et al., 6 Apr 2026).

The model configuration also differs by subtask. Generation uses temperature $\Theta$9 to encourage diversity and exploratory tests. Scoring and selection use temperature $t$0 to encourage more stable rankings. The evaluated LLMs are Gemini 3 Flash, GPT‑5.4 Mini, and Mistral Large 3, and each model is used both for generation and for scoring within a given run.

The paper positions the coverage map as the key feedback channel. At the beginning it may contain only “Branches discovered: 0.” After several rounds it may report recent marginal gain, average gain per step, and the most informative tests. After stagnation it may add an explicit warning that “Coverage has stagnated for 3 steps” and suggest that a fundamentally different approach may be needed. This closed-loop conditioning is a major distinction from single-step prompting regimes.

5. Empirical evaluation

The evaluation uses two benchmarks. TestGenEval Lite is derived from TestGenEval, built on SWE-Bench, and contains $t$1 file-level targets after excluding scikit-learn because of C-extension build issues. RepoExploreBench is introduced specifically for iterative exploration and corridor scenarios; it contains $t$2 modules from $t$3 popular PyPI packages, around $t$4K lines of Python total, and selects modules with at least $t$5 lines while avoiding tests-only and vendored or compat layers. All methods are evaluated under the same budget $t$6 scripts (Amayuelas et al., 6 Apr 2026).

The comparison set consists of Random, Greedy, CovGreedy, and CovQValue. Random generates $t$7 tests and selects one uniformly at random. Greedy uses the same generation pattern but asks the LLM to choose the candidate “most likely to cover new code paths,” based only on the code and without the coverage map. CovGreedy augments generation with the coverage map and instructs the LLM to target undiscovered branches, but still selects randomly among the candidates. CovQValue uses $t$8 plans of $t$9 scripts, includes the coverage map, applies diversity hints, and chooses the plan with the highest estimated curiosity Q-value.

The main quantitative result is that CovQValue outperforms greedy selection on both benchmarks. On RepoExploreBench, the reported gains over Greedy are $a_t$0 to $a_t$1 branches, corresponding to approximately $a_t$2–$a_t$3 higher coverage. On TestGenEval Lite, the reported gains are $a_t$4 to $a_t$5 branches, corresponding to approximately $a_t$6–$a_t$7 higher coverage. The win rate over Greedy is $a_t$8–$a_t$9 across the three models, with paired $o_t$0-tests reported as $o_t$1 in all settings and Cohen’s $o_t$2 in the range $o_t$3–$o_t$4 (Amayuelas et al., 6 Apr 2026).

The coverage curves show a characteristic pattern. Random and Greedy plateau after approximately five steps. CovGreedy continues to climb because of coverage-map guidance. CovQValue climbs faster and often exhibits sharp jumps when traversing corridors. The case studies are consistent with this interpretation. In flask.app, Random and Greedy remain at $o_t$5 branches after $o_t$6 steps, whereas CovQValue reaches $o_t$7 branches by constructing the correct multi-step initialization sequence. In werkzeug.http, Greedy gets stuck at $o_t$8 branches, while CovQValue uses the coverage map to target parse_etags, parse_list_header, parse_dict_header, and then parse_options_header, dump_options_header, parse_cookie, and dump_cookie, producing jumps of $o_t$9 and $h_t = (a_1,o_1)\dots(a_t,o_t).$0 branches.

The ablations refine this picture. On RepoExploreBench with Gemini 3 Flash, coverage grows from about $h_t = (a_1,o_1)\dots(a_t,o_t).$1 branches at $h_t = (a_1,o_1)\dots(a_t,o_t).$2 to about $h_t = (a_1,o_1)\dots(a_t,o_t).$3 at $h_t = (a_1,o_1)\dots(a_t,o_t).$4, whereas Random stays near $h_t = (a_1,o_1)\dots(a_t,o_t).$5 even as $h_t = (a_1,o_1)\dots(a_t,o_t).$6 increases. With plan-length variation, longer plans provide additional gains beyond execution count alone. For the discount factor, the reported means are $h_t = (a_1,o_1)\dots(a_t,o_t).$7 branches for $h_t = (a_1,o_1)\dots(a_t,o_t).$8, $h_t = (a_1,o_1)\dots(a_t,o_t).$9 for $\Theta$0, and $\Theta$1 for $\Theta$2. A component ablation attributes substantial gains independently to the coverage map, diversity hints, and Q-value scoring.

6. Limitations, positioning, and disambiguation

The paper identifies several limitations. The Q-value estimator is heuristic: the LLM provides $\Theta$3 and $\Theta$4 from its internal understanding, with no guarantee of calibration or Bellman consistency. The coverage map is only a proxy posterior and does not encode explicit uncertainty or reachability probabilities. The method also incurs extra computational overhead because each round requires multiple LLM calls for both plan generation and Q-value scoring. In addition, the planning horizon is limited, the approach depends on branch-coverage instrumentation and Dockerized environments, and performance is sensitive to the code-understanding and ranking quality of the underlying model (Amayuelas et al., 6 Apr 2026).

Within LLM-based test generation, CovQValue is positioned against reactive or greedy systems such as CodaMosa, CoverUp, TELPA, and TestForge. Its distinctive move is not merely the use of coverage feedback, but the combination of a structured coverage map, multi-step plans, and explicit valuation of future reachability. This suggests a shift from one-shot coverage chasing toward exploration policies that treat test generation as an intrinsically sequential process.

A separate and unrelated usage appears in convex geometry. In the provided material on “Covariograms generated by valuations,” the label “CovQValue” is used for the valuation–covariogram quantity

$\Theta$5

where $\Theta$6 is a valuation on compact convex subsets of $\Theta$7. In that setting, the object generalizes Matheron’s covariogram, admits a convolution representation in the plane, and is studied in connection with reconstruction of convex bodies from overlap profiles (Averkov et al., 2013). The shared name therefore does not indicate a shared domain: the 2026 CovQValue method concerns curiosity-driven planning for LLM test generation, whereas the 2013 usage concerns valuation-generated covariograms in convex and stochastic geometry.