Code Testing Extensions

Rust Extension

Language-specific guidance for Rust test generation.

Rule #1: Investigate the Repo First

Before writing any test or running any command, read:

1. Existing tests — look at #[cfg(test)] mod tests blocks inside src/, integration tests in tests/, doc tests in source comments, and any examples/ that double as smoke tests

2. Cargo.toml — workspace layout ([workspace]), edition, dev-dependencies, feature flags, [[bench]] / [[test]] declarations

3. Cargo.lock — if checked in, you must not break it without intent

4. Toolchain — rust-toolchain.toml pins the channel (stable / nightly / specific version)

5. build.rs — custom build scripts may set cfg flags or generate code that tests rely on

Match the repo's existing conventions — assertion macros, mock approach, feature-gating — exactly. Do not introduce tokio::test if the repo uses async-std, etc.

Toolchain Detection

Build Commands

cargo check is far faster than cargo build and catches almost the same errors. Prefer it during the fix loop; use cargo build --tests (or cargo test --no-run) before declaring tests compilable.

Test Commands

• Arguments before -- are for cargo; arguments after -- go to the test binary

• cargo test foo runs every test with foo in its full path (module::tests::foo_does_a_thing) — to avoid surprise matches use --exact

• cargo nextest run is significantly faster if the repo already uses it (Cargo.toml [profile.nextest...] or .config/nextest.toml) — match the repo's choice

Lint Command

Use the repo's lint script first. Otherwise:

• cargo fmt --all -- --check (CI), cargo fmt (apply)

• cargo clippy --all-targets --all-features -- -D warnings

• If clippy.toml / rustfmt.toml exists, the project has opinions — never override them in your tests

Project Layout

my_crate/
├── Cargo.toml
├── src/
│   ├── lib.rs        # library crate root
│   ├── main.rs       # binary crate root (mutually OK with lib.rs)
│   └── module.rs     # private/public module
├── tests/            # integration tests — each .rs is a separate crate
│   └── widget.rs
├── benches/          # cargo bench targets
└── examples/         # cargo run --example name

• Unit tests at the bottom of module.rs:

  Copy

  #[cfg(test)]
  mod tests {
      use super::*;
  
      #[test]
      fn name_scenario_expected() {
          // ...
      }
  }

• Integration tests import the crate by name: use my_crate::PublicType;

• Helpers shared between integration tests must live in tests/common/mod.rs (the mod.rs form prevents cargo from treating them as a top-level test crate)

Test Function Patterns

Pick the async harness the repo already uses. Do not mix tokio and async-std in tests.

Common Errors

Mocking Rules

Rust has no single dominant mocking framework. Match the repo:

• Trait + struct fakes (most idiomatic): define a trait, pass Arc<dyn Trait> or generic T: Trait, implement a fake struct in tests

• mockall crate: #[automock] on a trait generates MockTrait for use in tests

• mockito / wiremock: HTTP server mocks for client tests

• tempfile: scoped temp directories that auto-clean (tempfile::tempdir())

Avoid unsafe patches to "mock" free functions. Refactor to inject a trait instead. If a test needs more than 3 mocks, flag it as a design smell.

Features and cfg

• Tests behind a feature flag run only when that feature is enabled — use #[cfg(feature = "foo")] on the mod tests or individual #[test] functions

• --all-features exercises everything but may pull conflicting features in some workspaces; check cargo test --all-features is part of CI before relying on it

• Use #[cfg(test)] to gate test-only helpers in production source files — not #[cfg(feature = "test")]

Concurrency, IO, and unsafe

• Tests run in parallel by default. If your tests share global state (env vars, current dir, statics), serialize them with the serial_test crate (if present) or move state into the test

• Never write to /tmp or the repo dir directly — use tempfile::tempdir() so cleanup is automatic

• Tests in unsafe code should also run under Miri (cargo +nightly miri test) if the repo's CI does

Dependency Installation (Last Resort)

Only add dependencies after investigation confirms they are missing:

[dev-dependencies]
mockall = "0.12"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

Or via cargo:

cargo add --dev mockall
cargo add --dev tokio --features macros,rt-multi-thread

Match the major version of any tokio/serde/etc. already pinned by the workspace.

Skip Coverage Tools

Do not configure or run coverage tools (cargo tarpaulin, cargo llvm-cov, grcov). Coverage is measured separately by the evaluation harness.