From Resource Flow to Executable Tests: Petri-Net-Guided LLM Test Generation for Concurrent Stateful Rust APIs

Source

• Source name: arXiv
• Source kind: paper
• Authors / organization: Kaiwen Zhang, Guanjun Liu
• Venue: arXiv: cs.SE
• Published: 2026-07-23
• Collected: 2026-07-24
• URL: http://arxiv.org/abs/2607.21530v1
• PDF: https://arxiv.org/pdf/2607.21530v1
• DOI: UNKNOWN

Plain-Language Brief

The authors present a methodology using Petri nets to generate tests for concurrent stateful Rust APIs, aiming to bridge the gap between formal scenario design and low-cost test concretization.

What the Document Says

• Concurrent stateful library APIs are studied with evolving resource ownership, lifecycle states, and competing interleavings.
• Large language models can synthesize Rust tests but often violate API preconditions or reduce concurrency to accidental sequential traces.
• Model-based and systematic testing techniques provide semantic control but require substantial handwritten code for test execution.
• A Petri-net-guided methodology is proposed for test generation over concurrent stateful Rust APIs, using colored tokens and transitions to represent resources, lifecycle conditions, and causal dependencies.
• Legal deep-state, near-legal, and partial-order concurrent scenarios are derived from the model, serving as a constrained intermediate representation for LLM-based code synthesis.
• A local-faithfulness contract and structural repair loop ensure preservation of the modeled intent during concretization.
• Petri-guided schedule shaping prioritizes high-conflict concurrency skeletons for systematic exploration.
• A layered semantic oracle distinguishes synthesis failures from violations of the target API's expected behavior.

Key Concepts Mentioned

• Petri nets
• Concurrent stateful APIs
• Large language models
• Rust programming language
• Test generation
• Concurrent scenarios

Claims Made by the Document

• Large language models often violate API preconditions or reduce concurrency to accidental sequential traces.
• Model-based and systematic testing techniques require substantial handwritten code for test execution.
• The proposed Petri-net-guided methodology can bridge the gap between formal scenario design and low-cost test concretization.

Evidence Used

• Violations of API preconditions and reductions in concurrency were observed in large language models.
• Substantial handwritten code is typically required for model-based and systematic testing techniques.
• The methodology presented addresses these issues by using Petri nets and other described methods.

Methods / Approach

UNKNOWN

Limitations Stated by the Authors

UNKNOWN

Limitations Noted by the Agent

Agent interpretation — not from the source.

UNKNOWN

Open Questions

UNKNOWN

Notes for Future Q&A

May include interpretation. Labeled where it does.

UNKNOWN

Raw Abstract / Excerpt

Concurrent stateful library APIs expose behavior through evolving resource ownership, lifecycle states, and competing interleavings. Large language models can synthesize executable Rust tests, but their outputs often violate API preconditions, remain shallow, or reduce concurrency to accidental sequential traces. Conversely, model-based and systematic testing techniques provide semantic control but commonly require substantial handwritten code to turn abstract scenarios into executable tests. This paper addresses the gap between formal scenario design and low-cost test concretization. We present a Petri-net-guided methodology for test generation over concurrent stateful Rust APIs. The method represents API resources, lifecycle conditions, and causal dependencies as colored tokens and transitions; derives legal deep-state, near-legal, and partial-order concurrent scenarios; and uses these scenarios as a constrained intermediate representation for LLM-based code synthesis. A local-faithfulness contract and structural repair loop preserve the modeled intent during concretization, while Petri-guided schedule shaping prioritizes high-conflict concurrency skeletons for systematic exploration. A layered semantic oracle then distinguishes synthesis failures from violations of the target API's expected behavior.