Source-linked AI summary

QTestBench: A Test Framework for Evaluating LLM-Generated Quantum Code

Meriem Terki, Nouhaila Innan, Minghao Shao, Muhammad Kashif, Alberto Marchisio, Muhammad Shafique

arXiv:2610.13811v1cs.LGcs.CLquant-ph

TL;DR

Quantum benchmarks evaluate whether LLMs generate correct programs, but not whether their tests distinguish correct from faulty quantum code. QTestBench evaluates generated test suites against independent benchmark checkers, finding that tests run reliably while discrimination remains a bottleneck.

  • Problem

    Quantum outputs are probabilistic, tolerances matter, and existing benchmarks assess solution correctness rather than whether generated tests distinguish correct from faulty code.

    Source: §I · p. 1
  • Method

    QTestBench generates syntactic, semantic, and behavioral tests, then compares their verdicts with independent checker labels under three validation cohorts.

    Source: §I · p. 1, D. Validation Configurations · p. 4, §V · p. 8
  • Results

    Generated tests run reliably, but discrimination remains the primary bottleneck; Claude Opus 4.6 reaches TQS = 0.71 on QHack, while Qiskit scores are lower and more heterogeneous.

    Source: §IV · p. 6, §V · p. 8
  • Takeaways & Limitations

    Scoring tests against benchmark oracles assesses a dimension of quantum LLM evaluation that solution-centric benchmarks do not cover.

    Source: §V · p. 8

    The evaluation uses temperature 0.8, a single generation pass without repair, ten selected Qiskit tasks, and benchmark-specific checker oracles.

    Source: D. Cross-Framework Synthesis · p. 8

Abstract

from arXiv · show

Large language models (LLMs) have shown strong results in classical code generation and are increasingly used to write the unit tests that safeguard that code. Whether they can do the same for quantum software is less clear, because quantum programs are probabilistic, depend on numerical tolerances, and are judged by domain-specific checkers, so a well-formed test can still disagree with the benchmark's verdict. Existing quantum benchmarks measure whether a model produces a correct solution, but not whether its tests can distinguish correct implementations from faulty ones. We introduce QTestBench, a framework that evaluates LLM-generated quantum test suites against independent benchmark checkers, never treating the tests themselves as ground truth. For each task, QTestBench prompts models to produce syntactic, semantic, and behavioral tests, injects candidate solutions at runtime, and compares each test verdict with the checker's label under three validation cohorts, each answering a distinct diagnostic question. We benchmark five LLMs on eight PennyLane QHack challenges and ten Qiskit HumanEval tasks. Generated suites almost always execute, but discrimination lags behind: the best generator reaches a test quality of 0.71 on QHack and 0.34 on Qiskit HumanEval, so executability alone overstates test quality. Oracle-verified synthetic mutants stabilize bug-detection estimates when natural faulty solutions are scarce, as on three of ten Qiskit tasks that yield none. QTestBench offers a reproducible, cross-framework benchmark for the trustworthiness of LLM-generated quantum tests.

I. INTRODUCTION

Quantum benchmarks assess whether models produce correct solutions, not whether their tests distinguish correct from faulty quantum code. QTestBench evaluates generated tests against independent checkers, and the Coffee Conundrum examples show valid tests can still disagree with the checker.

I. INTRODUCTION

  • Existing quantum benchmarks evaluate solution correctness but not whether generated tests distinguish correct from incorrect quantum programs.Quantum outputs are probabilistic, numerical tolerances matter, and correctness is often defined by domain-specific checkers.Source: §I · p. 1
  • QTestBench assesses whether generated tests execute, accept oracle-correct candidates, and reject oracle-wrong candidates against an independent benchmark oracle.The generated tests are evaluated, never treated as ground truth.Source: §I · p. 1

A. Motivational Case Study

  • The Coffee Conundrum case compares generated pytest verdicts with the benchmark checker on injected trusted and LLM-generated candidate solutions.The task returns a numeric answer as a string and provides two official input/output pairs.Source: A. Motivational Case Study · p. 1
  • One syntactic suite accepts incorrect LLM solutions without running official inputs, while a semantic suite rejects the human reference over a tolerance difference.Both test modules are valid Python, yet their verdicts disagree with the checker; these mismatches surface when tests, rather than only generated code, are graded.Source: A. Motivational Case Study · pp. 1–2

B. Research Challenges

Evaluating quantum tests requires independent ground truth, enough faulty candidates to estimate bug detection, and measures that transfer across SDKs. QTestBench addresses the gap with oracle-grounded test evaluation, discrimination metrics, and three validation cohorts.

B. Research Challenges

  • Quantum test evaluation must address solution-focused benchmarks, independent ground truth, scarce wrong solutions, and cross-SDK task differences.These challenges motivate measuring tests rather than only generated quantum solutions.Source: B. Research Challenges · p. 2

C. Our Contributions

  • QTestBench generates syntactic, semantic, and behavioral test modules and scores them against benchmark checkers that label candidates correct, wrong, or unknown.Its contributions also define test-quality metrics and three cohorts for assessing acceptance, discrimination, and calibrated rejection.Source: C. Our Contributions · p. 2
  • The evaluation spans five LLMs, eight QHack challenges, and a fixed ten-task Qiskit HumanEval scope using shared metrics across PennyLane and Qiskit.The models are Claude Opus 4.6, DeepSeek V3.2, Gemini 3 Pro, GPT-5.4, and Qwen3-Coder.Source: C. Our Contributions · p. 2

A. LLM Code Generation and Evaluation

  • Classical code benchmarks score generated code, but do not assess whether generated tests reliably distinguish correct from incorrect implementations.Related work includes text-similarity, execution-aware, and formal correctness evaluation approaches.Source: A. LLM Code Generation and Evaluation · p. 2

B. LLM Quantum Code Generation

Quantum code-generation work evaluates whether models produce correct programs, while QTestBench targets the unmeasured reliability of their generated tests. It uses independent benchmark checkers in a shared two-stage workflow across PennyLane QHack and Qiskit HumanEval.

B. LLM Quantum Code Generation

  • Quantum code-generation studies cover SDK-specific datasets, tools, and benchmarks, but evaluate solution correctness rather than test-suite discrimination across SDKs.Quantum tasks involve probabilistic outputs, domain-specific checkers, and circuit, simulation, or hardware-oriented APIs.Source: B. LLM Quantum Code Generation · p. 2

C. Trusting LLM-Generated Artifacts

  • QTestBench uses benchmark checkers as independent ground truth because generated artifacts, including tests, should be checked against a separate source of truth.A suite that passes broken code can be misleading.Source: C. Trusting LLM-Generated Artifacts · p. 2

D. Test Oracles and Mutation Testing

  • QTestBench uses official checkers as oracles and oracle-verified synthetic mutants when naturally wrong solutions are too sparse for stable bug-detection estimates.Mutation testing inserts faults into correct programs and scores suites by mutant detection.Source: D. Test Oracles and Mutation Testing · p. 3

III. METHODOLOGY

  • The two-stage workflow first generates pytest modules, then injects candidate solutions and compares test outcomes with independent benchmark checkers.The same workflow applies to both SDKs; task materialization and oracle execution differ.Source: §III · p. 3

A. Benchmark Tasks and Inputs

  • Tasks are materialized with prompts, stubs, official cases, and checkers; Qiskit results use a fixed ten-task scope selected before test generation.The reference solution is withheld from generation prompts, and the checker labels candidates correct, wrong, or unknown.Source: A. Benchmark Tasks and Inputs · p. 3

B. Automated Test Generation (Stage 1)

Stage 1 generates separate syntactic, semantic, and behavioral pytest modules using a reproducible four-step procedure. The modules differ in what they check and, for behavioral tests, in how they invoke candidate code across the two SDKs.

B. Automated Test Generation (Stage 1)

  • Stage 1 prepares each task, builds a test-type-specific prompt, queries the model once, then normalizes and grounds the generated suite.The reference solution is excluded from prompts, and no repair or re-prompt loop is used.Source: B. Automated Test Generation (Stage 1) · p. 3
  • Syntactic tests check Python validity, harness loading, and required entry points; semantic tests execute official cases with atol = 10−4.Syntactic tests do not execute circuits.Source: B. Automated Test Generation (Stage 1) · p. 3
  • Behavioral tests use QHack template-local run()/check() helpers, but invoke the injected entry point end-to-end on Qiskit.QHack behavioral checks use harness acceptance rather than the official Stage 2 oracle.Source: B. Automated Test Generation (Stage 1) · p. 3

C. Discrimination Metrics

The section defines scores for whether generated suites execute, accept oracle-correct candidates, and reject oracle-wrong candidates. It combines these measures into test quality and composite quality, with explicit handling when no wrong candidates are available.

C. Discrimination Metrics

  • A validation cohort separates oracle-correct candidates from oracle-wrong candidates; unknown candidates are excluded, and a suite accepts only when all its test functions pass.A failure or error counts as rejection.Source: C. Discrimination Metrics · p. 3
  • Executability score (ES) indicates whether a suite runs on the trusted-correct baseline without infrastructure failure.ES is 1 on success and 0 otherwise.Source: C. Discrimination Metrics · p. 3
  • Correctness score (CS) is the fraction of oracle-correct candidates accepted by the generated tests.Source: C. Discrimination Metrics · p. 4
  • Bug-detection score (BDS) is the fraction of oracle-wrong candidates rejected, and is undefined when the cohort has no oracle-wrong candidates.Source: C. Discrimination Metrics · p. 4
  • Test quality score (TQS) is ES × CS in Configuration A and ES × CS × BDS in Configurations B and C when wrong candidates exist.When a cohort has no oracle-wrong candidates, BDS, TQS, and composite quality (CQ) are n/a; CQ is √TQS × checker-input coverage (Cin) when TQS is defined.Source: C. Discrimination Metrics · p. 4

D. Validation Configurations

Stage 2 evaluates generated suites under three validation cohorts, each designed to answer a different diagnostic question. The cohorts progress from trusted-correct reference code to natural LLM solutions and oracle-verified synthetic mutants.

D. Validation Configurations

  • Configuration A probes only the canonical reference solution, isolating executability and acceptance of known-correct code; TQS equals ES × CS because BDS is undefined.Source: D. Validation Configurations · p. 4
  • Configuration B adds independently generated LLM solutions labeled by the checker to measure discrimination against naturally occurring wrong implementations.When there are no wrong probes, BDS, TQS, and CQ are n/a.Source: D. Validation Configurations · p. 4
  • Configuration C adds reference-solution mutants retained only when the oracle confirms they are wrong, supplying calibrated negatives when Configuration B lacks them.Source: D. Validation Configurations · p. 4

E. Validation and Scoring (Stage 2)

Stage 2 labels candidate solutions with the benchmark checker, runs generated tests through runtime injection, and aggregates scores by test type, task, and generator. The experimental design fixes tasks, models, prompts, mutant generation, and aggregation rules.

E. Validation and Scoring (Stage 2)

F. Experimental Design

  • The evaluation fixes eight QHack challenges and ten Qiskit HumanEval tasks across five LLM test generators, with each model and configuration using the same tasks.Generation uses one call per test type at temperature 0.8, with no repair loop.Source: F. Experimental Design · p. 5
  • Prompts request self-contained pytest modules with at least three tests, candidate loading, and atol = 10^-4, while tailoring requested checks to test type and SDK.Edge cases and fixed seeds are soft guidance, not enforced scoring requirements.Source: F. Experimental Design · p. 5
  • Configuration C applies deterministic mutations to the reference and retains only candidates the official checker labels wrong.Up to twelve candidates are tried and the first three wrong probes kept; probes run in isolated temporary directories with runtime injection.Source: F. Experimental Design · p. 5
  • Table aggregates average scores bottom-up across suite types, generators, and tasks; BDS, TQS, and CQ are n/a when no wrong probes exist.Model-level BDS and CQ use only tasks with wrong probes, and Qiskit Configuration B omits TQS because three tasks have no wrong probes.Source: F. Experimental Design · p. 5

IV. RESULTS AND DISCUSSION

The results section asks whether suites execute and accept correct code, catch naturally occurring LLM bugs, and detect injected faults. Across both benchmarks, generated tests run, but accept correct code better than they reject incorrect code.

IV. RESULTS AND DISCUSSION

  • The evaluation considers execution and acceptance under Configuration A, bugs from LLM solutions under B, and injected faults under C.Source: §IV · p. 5
  • Table III presents a Configuration B scoring ledger for Chalet Random Gate, with probe counts followed by CS, BDS, and TQS averaged over test types.Source: Table III · p. 6
  • Across both benchmarks, generated suites run reliably but are better at accepting correct code than rejecting incorrect code.Source: §IV · p. 6

A. QHack Results

On QHack, reliable execution and strong acceptance do not guarantee bug discrimination; on Qiskit, test quality varies widely across tasks, and some natural-solution cohorts contain no wrong candidates.

A. QHack Results

  • Under QHack Configuration A, executability is at least 0.79 for every model, but Gemini 3 Pro leads acceptance with CS = TQS = 0.96.Source: A. QHack Results · p. 6
  • Claude Opus 4.6 leads QHack test quality with TQS = 0.69 and 0.71 in Configurations B and C, pairing strong acceptance with the best bug detection.Source: A. QHack Results · p. 6
  • Coffee Conundrum reaches only TQS = 0.13 despite Cin = 0.97, showing that checker-input coverage alone does not ensure discrimination.Source: A. QHack Results · p. 6

B. Qiskit HumanEval Results

  • On Qiskit Configuration A, Claude Opus 4.6 leads acceptance with CS = TQS = 0.77, while task quality ranges from TQS = 0.87 for Bell-state simulation to 0.13 for GHZ-state construction.Source: B. Qiskit HumanEval Results · p. 6
  • Qiskit Configuration B yields middling bug detection (BDS = 0.45–0.60), and three of ten tasks have no wrong solutions, leaving BDS, TQS, and CQ undefined.Source: B. Qiskit HumanEval Results · p. 6
  • With verified mutants in every task, Qiskit Configuration C makes BDS measurable, but the top test quality is only Gemini 3 Pro’s TQS = 0.34.Source: B. Qiskit HumanEval Results · p. 6

C. Metric Case Studies

The case studies show how test verdicts can diverge from oracle labels in opposite directions, while absent wrong candidates can leave a task’s score undefined.

C. Metric Case Studies

  • The aggregate results identify discrimination as the bottleneck, and Fig. 4 illustrates this with three concrete cases.Source: C. Metric Case Studies · p. 6
  • On Mach–Zehnder Cabin, a GPT-5.4 syntactic suite accepts all correct probes but also passes oracle-wrong solutions that never run on official inputs, yielding BDS = 0 and TQS = 0.Source: C. Metric Case Studies · pp. 6–7
  • On Contextuality Dunes, a DeepSeek V3.2 suite rejects the correct human reference, giving BDS = 1, CS = 0, and TQS = 0.Source: C. Metric Case Studies · p. 7
  • On create_ghz, Claude Opus 4.6 has BDS/TQS n/a in Configuration B because |Sw| = 0, but BDS = 0.83 in Configuration C; low CS = 0.13 caps TQS at 0.03.Source: C. Metric Case Studies · p. 8

D. Cross-Framework Synthesis

QTestBench applies consistent test-evaluation metrics across PennyLane QHack and Qiskit HumanEval. Generated suites generally execute, but their ability to distinguish correct from faulty solutions remains limited, especially on Qiskit.

D. Cross-Framework Synthesis

  • Executability rarely limits suites (ES ≥0.93 for most pairs), while CS and BDS distinguish generators.On QHack, four models achieve ES ≈1.00, but bug detection remains moderate.Source: D. Cross-Framework Synthesis · p. 8, §V · p. 8
  • On QHack, Configurations B and C agree closely; on Qiskit, Configuration C restores defined BDS for three tasks with no pooled TQS under Configuration B, but TQS remains moderate.Absolute TQS depends on probe composition, and BDS is n/a when |Sw| = 0.Source: D. Cross-Framework Synthesis · p. 8
  • High Cin alone does not ensure bug detection: Coffee has Cin = 0.97 but TQS = 0.13, matching the weak pattern illustrated by Case A on Mach–Zehnder Cabin.The paper identifies execution-feedback refinement as a natural next step for single-pass generation.Source: D. Cross-Framework Synthesis · p. 8
  • The evaluation uses temperature 0.8, a single generation pass without repair, ten selected Qiskit tasks, and benchmark-specific checker oracles.These conditions bound the reported evaluation.Source: D. Cross-Framework Synthesis · p. 8

V. CONCLUSION

  • QTestBench unifies PennyLane QHack and Qiskit HumanEval in a two-stage pipeline and reports test-quality measures with consistent definitions across SDKs.It generates syntactic, semantic, and behavioral pytest modules, then validates them under three cohort configurations.Source: §V · p. 8
  • TQS reaches 0.71 for Claude Opus 4.6 on QHack, while Qiskit peaks at 0.34 for Gemini 3 Pro and has more task-heterogeneous scores.The Qiskit results also reflect sparser wrong probes and fewer extractable checker literals.Source: §V · p. 8, D. Cross-Framework Synthesis · p. 8
Loading 2610.13811v1…