# Write Unit Tests for a Rust Project Yes. An agent runs Rust test coverage, adds tests for the least-covered logic modules, and opens a pull request with the coverage delta. [Run this on Rush](https://cloud.getrush.ai/run/write-unit-tests/rust/), in a Project that has your repository. ## What the agent does The agent reads the crate layout and how tests are already organised. In sharkdp/fd it opens `Cargo.toml` for the `fd-find` package: binary `fd` at `src/main.rs`, dependencies such as `clap` `4.6` with derive features, `ignore`, `regex`, `aho-corasick`, `jiff`, and optional `clap_complete` / jemalloc features. Dev-dependencies include `tempfile`, `filetime`, `diff` and `test-case`. Integration coverage lives mainly in `tests/tests.rs` with a `testenv` helper; unit-style modules under `src/` include `filter/size.rs`, `filter/time.rs` and `filter/owner.rs` (each already embedding `#[cfg(test)]` modules), plus `regex_helper.rs`, `sanitize.rs`, `filesystem.rs`, `walk.rs`, `exec/`, `fmt/` and `output.rs`. It runs the suite with coverage via `cargo llvm-cov` when that is available in the sandbox, or `cargo tarpaulin` / `RUSTFLAGS` instrumentation otherwise, and ranks `src/**/*.rs` by missed lines. Candidates with real branching include `sanitize.rs` (`needs_escape`, `write_sanitized` for control and bidi characters), `regex_helper.rs` (`pattern_has_uppercase_char`, leading-dot detection), `filter/size.rs` parse edge cases not already in its inline tests, `exec/command.rs` / `exec/job.rs`, and hyperlink formatting in `hyperlink.rs`. Pure `main.rs` wiring stays low priority when logic is already extracted. New tests prefer `#[cfg(test)]` modules inside the same file when that matches fd's filter modules, or new files under `tests/` when the behaviour is integration-shaped (temp directories with `tempfile`, mtime with `filetime`). Cases use `test-case` where neighbouring tests do. They assert observable behaviour: sanitized escape sequences, size constraint parsing errors, regex smart-case decisions, not private struct layouts. After the new tests pass under `cargo test --all` (and the crate's default features), the agent writes coverage before/after into the pull request description. Production code changes only for a bug the tests exposed, called out explicitly. Feature flags such as `completions` are exercised only when the thin file sits behind them. Cross-compilation targets in `Cross.toml` and release stripping in `[profile.release]` stay out of the test loop; the sandbox runs host `cargo test` only. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "claude", "input": "Run the test suite with coverage, pick the five least-covered files that hold real logic, and write Rust tests for them that exercise behaviour, not implementation details. Do not change production code unless a test reveals a bug; if it does, say so in the description. Open a pull request with the coverage before and after.", "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 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 on a new branch. In an fd-shaped crate it extends `#[cfg(test)]` modules or `tests/tests.rs` helpers, leaves `src/main.rs` alone unless a bug fix is required, and does not churn `Cargo.lock` except when a dev-dependency for coverage tooling must be added. The description names the five files, the coverage tool used, and the before/after figures. The trajectory keeps `cargo test` and coverage command output, including any feature-flag combinations that were required for a thin module. Before merging, a reviewer checks that filesystem tests use temporary directories, that sanitizer tests include representative Unicode edge cases, and that default feature builds stay green. Once merged, the existing CICD workflow runs the new tests on the same host targets the project already uses. ## Run it on every release cut preparation Before tagging a release, have your server send this request so the thinnest modules gain tests while the crate is still soft. Point `resources` at the release branch. Handle `run.completed` through the API key webhook and attach the coverage delta to the release checklist. Keep concurrency low; coverage builds are heavier than plain `cargo test`. ## Why run it on Rush? Rust coverage tooling and integration tests that touch the filesystem are messy beside daily editing. On Rush the agent installs the coverage helper in its sandbox, runs the suite, adds focused tests next to fd's existing style, and opens a pull request that already passes `cargo test`. The coverage delta on the pull request is the proof. The same job can harden several crates overnight, each with its own reviewable diff. ## Frequently asked questions ### Inline #[cfg(test)] or tests/ integration tests? Follow the file. Filters in fd keep unit tests inline; broad CLI behaviour stays under `tests/tests.rs` with `testenv`. The agent does not invent a third harness. ### Which coverage tool? Whatever the sandbox can run cleanly with the crate — typically `cargo llvm-cov` when llvm tools are present. The pull request states which command produced the numbers. ### Will it enable every Cargo feature? Default features first (`use-jemalloc`, `completions` on fd). It enables optional features only when the uncovered file needs them, and says so in the description. ### Does it benchmark or only test? Only tests and coverage for this job. Benchmarks and Cross.toml targets stay out of scope. Performance numbers from the README are never invented or restated as if the sandbox measured them.