---
title: 'QuickChick: Coq Property-Based Testing'
url: https://www.emergentmind.com/topics/quickchick
type: topic
---

# QuickChick: Coq Property-Based Testing

QuickChick is a property-based testing framework for Coq that is used to test executable specifications, programs, compilers, and proof-relevant semantic artifacts by generating structured randomized inputs and checking propositions after reifying them into executable tests. Across the literature represented here, it appears not as a substitute for mechanized proof, but as a complementary layer for early bug discovery, specification validation, regression testing, approximation analysis, and generation of valid semantic traces inside larger proof-oriented developments. Its distinctive role is most visible when the surrounding formalization makes the target artifact executable enough to sample—such as interaction trees for networked systems, execution traces for smart contracts, type-disciplined oracle languages for quantum computing, and transition systems for timed reactive models [1811.11911] [2012.09138] [2112.06700] [2501.05616].

## 1. Definition and methodological role

In the papers considered here, QuickChick is consistently presented as a Coq plugin or property-based testing framework for Coq. Its operational role is to turn formal propositions into executable randomized tests, generate many test cases automatically, and report trustworthy counterexamples when the ambient framework ensures that generated executions are semantically valid or that the testing infrastructure itself is formally verified. In the ConCert smart-contract setting, QuickChick is described as a formally verified framework in Coq, which is one reason a reported counterexample is treated as trustworthy [2012.09138].

A recurrent methodological pattern is a four-stage workflow: write the artifact in Coq, test it with QuickChick, verify properties in Coq, and then extract or compile executable code. This exact sequencing is stated for ConCert smart contracts, where QuickChick is the early discovery and sanity-check phase before full verification and extraction [2012.09138]. The networked-server verification pipeline follows the same logic: QuickChick tests the compiled C code and the implementation model against a linear specification, VST verifies the C code against the model, and pure Coq proof establishes the refinement relation between model and specification [1811.11911]. Quantum frameworks adopt the same division of labor: in VQO, QuickChick provides an “easy-to-use confidence boost” before or alongside proof, while Coq proofs establish OQASM soundness and OQASM-to-SQIR compiler correctness [2112.06700]. Pqasm likewise uses QuickChick as the executable testing backend for a Coq-verified framework, with type soundness and progress providing the formal context in which randomized testing is meaningful [2501.05616].

A common misconception is that QuickChick is merely lightweight fuzzing. The papers do not support that reading. In several case studies, it is instead a semantics-aware testing layer over executable formal models, often generating only valid traces, valid transitions, or basis-state instances justified by a formal reduction. This suggests that QuickChick’s practical significance depends less on randomness per se than on the structure of the surrounding Coq development.

## 2. Executable propositions, traces, and test schemas

The properties tested with QuickChick vary by domain, but several recurring schemas are explicit. In ConCert, the testing framework supports three kinds of testable properties: universal properties over `ChainBuilder`,
$$
\forall (c : ChainBuilder),\ P\ c,
$$
Hoare-style pre/post specifications for `receive`,
$$
\{pre\}\ \text{SomeContract.receive}\ \{post\},
$$
and reachability properties over chain states,
$$
init\_chain \ \leadsto\ (fun\ cs : ChainState => P\ cs).
$$
The paper emphasizes that the first form—properties over entire traces—is the most distinctive, because it supports interacting smart contracts rather than isolated calls [2012.09138].

QuickChick also operates over relational specifications rather than simple input-output equalities. For the swap server, the tested property is a network refinement condition: an observed network trace is accepted if some reordering of that trace is a valid trace of the linear specification. The Coq definitions of `impl_behavior`, `spec_behavior`, and `network_refines` make this explicit, and QuickChick checks sampled traces against precisely that refinement notion rather than exact trace equality [1811.11911]. In VQO, the target properties include functional correctness of arithmetic and oracle operators, correctness of OQASM programs against a Coq specification on Nor-basis inputs, compiler-pipeline consistency at the OQASM level, regression-style bug detection, and relational properties comparing exact and approximate circuits such as QFT versus AQFT [2112.06700].

The framework also supports implication-style testing with discarded cases. In the smart-contract paper, QuickChick internally turns a proposition into an executable form using a testable implication operator `==>` that discards tests when the precondition is false, illustrated by:
```coq
Conjecture example_prop :
  forall (x y : nat), y = square x -> sqrt y = x.
QuickChick example_prop.
(* Passed 10000 tests (0 discards) *)
```
The same paper reports a contract property tested as:
```coq
QuickChick (forall c : ChainBuilder, escrow_correct_P c).
(* Passed 10000 tests (23743 discards) *)
```
which makes the role of discards operationally explicit [2012.09138].

For timed reactive systems, the oracle is partly implicit in generation: `genValidTrace` builds traces only from the model’s own transition relation, so generated traces are guaranteed to be valid traces of the DFRS semantics [1910.13553]. In Pqasm, correctness properties over state-preparation programs are reduced from superposition-level statements to basis-ket properties, so QuickChick checks randomly generated basis-state instances against user-specified properties after the initial `new` and `H` front matter is removed [2501.05616].

## 3. Generator design and validity-preserving sampling

A central technical theme is that QuickChick is most effective when generators are specialized to the semantics of the target language rather than fully generic or purely random. The ConCert integration is explicit on this point. Users provide specialized generators for each contract’s message type; from those, ConCert automatically derives generators of provably valid execution traces. This avoids the poor coverage that would result if purely random fuzzing produced many invalid messages that had to be discarded [2012.09138]. The escrow generator is representative:
```coq
Definition gEscrowMsg (e : Environment) (state : Escrow.State)
  : G (Option Action) :=
  let call caller amount msg :=
    ret (build_act caller (act_call contract_addr amount (serialize msg))) in
  backtrack
    [(1, if e.(account_balance) state.(buyer) <? 2
         then returnGen None
         else call state.(buyer) 2 commit_money) ;
     (1, call state.(buyer) 0 confirm_item_received) ;
     (1, addr <- elems [state.(seller); state.(buyer)] ;;
         call addr 0 withdraw) ].
```
Here `backtrack` chooses among candidate actions, but the resulting actions remain structured by contract-specific preconditions [2012.09138].

The same validity-preserving pattern appears in DFRS testing. The generator `genValidTrace : STATE -> s_DFRS -> ... -> nat -> G trace` recursively computes possible transitions with `genTransitions`, selects one transition from those available, moves to the successor state, and recurses until the size bound is exhausted. `genTransitions` itself branches on stability: if the current state is stable it generates delay transitions using the configured time step and possible input combinations; if unstable it generates function transitions corresponding to enabled guards and assignments [1910.13553]. QuickChick is therefore sampling from a formally defined transition system, not from raw unconstrained inputs.

In work on lambda-term families, generator design becomes a consequence of isomorphism engineering. The paper develops two representations for families such as closable Motzkin trees and parameterized open terms: a base type plus restriction predicate, and a more precise inductive representation. QuickChick derives generators automatically for ordinary inductive types such as `motzkin`, `closable`, `ucs`, and `lmt`, while handwritten size-aware generators are used for restricted families such as `rec_closable`, `rec_ucs`, and `rec_open`. The purpose is to generate valid objects directly and avoid invalid or highly discarded tests. For closable trees, the recommended check is:
```coq
QuickCheck (sized (fun n => forAll (gen_closable_struct n) is_closableb)).
```
and the paper reports success, with no discards [2212.10453].

Quantum applications make the same design choice for different reasons. In VQO, the generators are hand-crafted rather than fully generic because the intended inputs are Nor-basis bitstrings, and the language design ensures that states remain compactly representable and unentangled by construction [2112.06700]. In Pqasm, QuickChick generates random basis-ket test cases by treating Hadamard-qubit values as random variables over $\{0,1\}$ after stripping off the initial uniform-superposition front matter [2501.05616]. Across these domains, a plausible implication is that QuickChick’s scalability depends critically on generator specialization and semantic admissibility constraints.

## 4. Integration with formal verification, semantics, and compilation

QuickChick’s most characteristic deployments occur where the semantics being tested are already formalized in Coq and are executable enough to run. In the swap-server paper, interaction trees are the common representation connecting Coq, VST, and QuickChick. The linear specification is an executable `itree`, the implementation model is also an `itree`, and trace semantics are defined over these objects. Because interaction trees “work well with Coq-style program extraction, and hence with testing,” the same executable artifact serves simultaneously as specification, testing oracle, and proof target [1811.11911].

In ConCert, QuickChick is integrated as a property-based testing layer over executable smart-contract semantics. ConCert already provides an executable specification of smart contracts in Coq, a chain/execution-trace model, and a representation of contract interaction via blocks and actions. QuickChick then generates and tests `ChainBuilder` values, each of which contains a chain state plus a proof-relevant execution trace that led there [2012.09138]. The significance is not merely convenience: according to the paper, this is the first development to support property-based testing of interacting smart contracts via execution traces [2012.09138].

In VQO, the same pattern is instantiated for a verified compiler stack. OQASM is the efficiently simulable quantum assembly language at the center of the framework, OQIMP is the higher-level source language, and SQIR is the target of verified translation. QuickChick is applied directly to OQASM programs, and also to OQIMP programs by compiling them to OQASM and then testing the compiled result [2112.06700]. This complements the type soundness theorem for OQASM and the translation-correctness theorem from OQASM to SQIR. The paper also proves a linearity lemma showing that if a program acts correctly on each basis state, then it acts correctly on superpositions, which explains why basis-state testing is theoretically useful [2112.06700].

Pqasm extends that line of work from oracle-like quantum programs to state preparation. Its key move is a reduction from superposition-level correctness to basis-ket correctness for a restricted, well-typed class of state-preparation programs. QuickChick is used only after typechecking and after transforming the program into a reduced form suitable for classical randomized testing. The framework’s type preservation and progress theorems justify running the interpreter and testing infrastructure on well-typed programs [2501.05616].

These examples make clear that QuickChick is most powerful when embedded inside a proof-oriented semantics-and-compilation stack. It checks executable semantic artifacts that are later proved correct, rather than testing ad hoc implementations in isolation.

## 5. Applications and empirically reported outcomes

The empirical record represented in these papers is broad, spanning smart contracts, verified systems software, timed reactive embedded systems, quantum oracle compilation, quantum state preparation, and certified representations of lambda-term families.

In smart contracts, QuickChick is used to test properties over execution traces of escrow, congress/DAO-like, ERC-20, FA2, liquidity-exchange, and broader DeFi-style contracts. The escrow case study defines a net balance effect and tests the property that if a buyer sent `confirm_item_received`, then the buyer net effect is $-x$ and the seller net effect is $x$; otherwise both effects are $0$. The paper reports that manually introducing a bug in withdrawable amount calculation leads QuickChick to find a counterexample quickly. It also states that the framework could detect the famous DAO-style re-entrancy vulnerability and vulnerabilities analogous to the UniSwap/Lendf.me re-entrancy exploit and the iToken self-transfer minting bug [2012.09138].

In verified systems software, QuickChick tests the compiled C swap server and the implementation model against the linear specification. The paper’s mutation-testing experiment inserted 12 plausible bugs into the C code. For 5 of 12 mutants, the wrong behavior was caught by the first test in every run; for 6 more, the bug passed the first test in some runs but always failed by the second test. A `recv` mutant was slower to detect because liveness is not part of the specification, and in some runs the tester discarded up to 3000 tests where the server did not respond and took up to five minutes to fail. The remaining mutants could fail within 0.4 seconds with 95% confidence [1811.11911].

For timed DFRSs, QuickChick generated trace datasets for a vending machine and a priority command function from Embraer. The evaluation used 1, 5, and 10 sampling calls, each call performing 11 invocations of `genValidTrace`, with trace size bounded to `size = 100`. The paper reports an average mutation score of $75.80\%$, with VM mean `74.56%`, standard deviation `11.00%`, and PC mean `77.03%`, standard deviation `2.81%`. Generation times were also reported, including `7.03s / 0.63s` for VM and `7.39s / 0.80s` for PC at 10 calls, as mean / standard deviation [1910.13553].

In VQO, QuickChick found an endianness bug in the QFT adder, uncovered an issue in the original presentation of the QFT-based modular multiplier regarding endianness of the stored integers, and exposed another issue involving the modulus bound in multiplier proof obligations. The paper reports 10,000 randomly generated tests on 8-bit and 16-bit operators in a few seconds and 10,000 tests on 60-bit versions in a few minutes [2112.06700]. Pqasm reports 10,000 tests for each benchmark, validation of all five state-preparation programs on 60-bit inputs, and runtimes of 2.4s for \(n\)-basis-ket preparation, 19.7s for modular exponentiation, 24.9s for Hamming weight, 2.1s for amplitude amplification, and 658s for distinct-element preparation. The same 60-bit versions did not complete overnight in DDSim after SQIR/OpenQASM translation [2501.05616].

The lambda-term-family paper is less centered on performance metrics, but it shows another mode of use: QuickChick supports proof-carrying random generation, transport of generators across formally proved isomorphisms, and testing of conversion functions and restriction predicates on valid random data [2212.10453].

## 6. Limits, misconceptions, and related directions

The literature is unusually consistent on QuickChick’s limits. It is not a substitute for proof. VQO states this explicitly, framing QuickChick as confidence-building and bug-finding rather than full assurance [2112.06700]. The swap-server work likewise treats QuickChick as complementing, not replacing, VST and pure Coq proof [1811.11911]. ConCert presents testing as a cost-efficient preliminary step to verification and as a complementary technique when proofs are difficult or expensive [2012.09138].

Another misconception is that QuickChick necessarily tests arbitrary programs by brute-force simulation. The quantum papers show the opposite. VQO relies on OQASM’s restricted design and its guarantee of a non-entangled state space to keep simulation and testing tractable [2112.06700]. Pqasm restricts attention to a well-typed class of state-preparation programs and reduces superposition-level correctness to basis-ket testing on a classical machine [2501.05616]. This suggests that QuickChick’s success in advanced domains often depends on language design choices that preserve executability and compact state representations.

There are also explicit domain-specific limits. The swap-server tests do not cover liveness, which is why a server that stops responding can be “trivially correct” with respect to a partial-correctness specification [1811.11911]. The DFRS framework notes that a complete sound MBT theory would also require an implementation relation and a test execution procedure, together with a soundness proof for the generation/execution pipeline; these were not yet formalized [1910.13553]. Pqasm notes that the method does not support arbitrary quantum programs and that some probability properties may still require proof in Coq [2501.05616]. VQO observes that extraction and simulation introduce non-Coq components, including extracted OCaml code and manual spot-checking for bugs outside the Coq-verified core [2112.06700].

A useful related comparison appears in “QuickCheck for VDM,” which is not about QuickChick but is clearly aligned in spirit. That tool classifies proof obligations into FAILED, PROVABLE, MAYBE, UNCHECKED, and TIMEOUT, using pluggable strategies to generate counterexamples or probable witnesses. The comparison is instructive because it reinforces the broader pattern also seen with QuickChick: lightweight falsification and executable checking are most effective as a triage layer before heavier proof technology is applied [2410.02046].

Taken together, these works present QuickChick as a mature testing technology for Coq-centered verification pipelines: strongest when paired with executable semantics, structured generators, and proof-oriented modeling; limited when liveness, unrestricted state spaces, or weak semantic instrumentation prevent meaningful sampling.

Source: https://www.emergentmind.com/topics/quickchick