# Write Property-Based Tests for a Rust Library

Yes. An agent adds proptest properties for core parsers, runs a high case count, and opens a PR without changing library code on failure.

[Run this on Rush](https://cloud.getrush.ai/run/write-property-tests/rust-library/), in a Project that has your repository.

## What the agent does

The agent picks pure entry points with round-trip potential. In rust-lang/mdBook the workspace (`edition = "2024"`, `rust-version = "1.88.0"`) splits crates under `crates/`; `mdbook-summary` exposes `parse_summary` in `crates/mdbook-summary/src/lib.rs` building a `Summary` with prefix, numbered and suffix chapters; `mdbook-core` holds `Config` parsing from TOML in `crates/mdbook-core/src/config.rs` and path helpers such as `path_to_root` in `utils/fs.rs`. There is no `proptest` dependency in the workspace `Cargo.toml` today.

It adds `proptest` as a dev-dependency on the crate under test (for example `mdbook-summary`) and writes `#[proptest]` tests beside unit tests or under `tests/`. Strategies generate SUMMARY.md-like markdown (headings, linked chapters, separators, nested lists) and assert: successful parses produce structures that respect prefix-before-numbered ordering; clearly invalid nesting returns `Err`; lossless properties hold only where the parser documents them (the module comments describe ignored titles and unsupported elements). For config, round-trip TOML through `Config` where serde allows.

Runs use a raised `ProptestConfig::cases` (or `PROPTEST_CASES`) so thousands of inputs exercise the parser in the sandbox. On failure the agent keeps the shrunk INPUT in the test output / pull request and does not edit `parse_summary` or other production functions to silence the property.

It runs `cargo test -p mdbook-summary` (and any other package it extended) with the workspace's pinned Rust version, fixes strategy bugs only, and opens a pull request adding proptest tests and Cargo.dev-dependencies. When generating SUMMARY.md-like input it mirrors the grammar in the `mdbook-summary` module docs: optional `# Summary` title, prefix links, `# Part` titles, nested `- [name](path.md)` lists, horizontal rules as separators, and suffix links after numbered chapters. Strategies shrink toward the smallest markdown that still violates an invariant, which is what maintainers need when `parse_summary` returns `Ok` for a structure the docs call unsupported.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Write property-based tests with proptest for the core parsing and transformation functions of this library: round trips, idempotence and invariants. Run them with a high example count. Open a pull request; if a property fails, include the shrunk counterexample and do not change the library.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-rust-lib"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request that adds proptest cases to the chosen crate(s) and pins `proptest` in that crate's `Cargo.toml`. Production parsers stay unchanged when a counterexample appears; the shrunk markdown or TOML is quoted for maintainers.

The pull request description names the `cargo test -p …` command, the case count, and pass/fail per property. The trajectory includes proptest's shrinking log when a failure is intentional evidence.

Before merging, a reviewer checks that strategies match the SUMMARY.md grammar described in `mdbook-summary`'s module docs, that flaky over-broad strategies were not papered over with `filter` that hides bugs, and that CI's Rust version matches `rust-version = "1.88.0"`.

## Run it on every summary or config parser changed

When pulls touch `crates/mdbook-summary/**` or `crates/mdbook-core/src/config.rs`, POST this session body so proptest re-runs at high case counts before merge, in a sandbox with the workspace MSRV toolchain.

Notify via the API key webhook on `run.completed` / `run.failed` with the session URL. Treat a new counterexample as a bug report against the parser, not an automatic production patch.

## Why run it on Rush?

proptest at thousands of cases compiles and runs heavier than ordinary unit tests, especially across a workspace. Rush builds with the repo's Rust 1.88 toolchain in an isolated sandbox so your machine is free for other crates. Workspace members listed in the root `Cargo.toml` (`crates/*`) keep sharing `workspace.dependencies`, so the proptest pin stays local to the crate under test instead of forcing every member to compile it.

Failing closed on library changes when a property fails gives you a minimal SUMMARY.md counterexample in the pull request and the full `cargo test` log in the trajectory—the evidence maintainers need without noise from drive-by parser rewrites.

## Frequently asked questions

### Will it modify parse_summary if a property fails?

No. The job records the shrunk input and leaves production code alone. Fixing the parser is a separate, deliberate change.

### Which crate gets the tests?

The ones with clear pure parsers—primarily `mdbook-summary` for `parse_summary`, optionally `mdbook-core` for `Config`. The agent does not spray proptest across GUI or CLI crates without invariants.

### Does this replace the existing testsuite?

No. Integration coverage under `tests/` and crate unit tests remain. proptest adds randomised exploration on top.

### What Rust edition and MSRV?

mdBook's workspace uses edition 2024 and `rust-version = "1.88.0"`. The sandbox installs that toolchain (or newer compatible) before `cargo test`.