Recognize `rstest` and `rstest_parametrize` as test-only code in Whitaker

[leynos]

Problem statement

Whitaker currently fails to recognize test functions declared with #[rstest] or #[rstest_parametrize] as test-only code. That causes false positives in lints that intentionally forbid patterns such as .expect() or .unwrap() outside tests.

This is a Whitaker bug or gap in test-context detection, not an rstest bug.

Current behavior

Given code like this:

#[rstest]  
#[case::syntactic(LockFailureKind::Syntactic, "syntax error")]  
#[case::semantic(LockFailureKind::Semantic, "type error")]  
fn content_transaction_rejects_lock_failure(  
    #[case] kind: LockFailureKind,  
    #[case] message: &str,  
) {  
    let dir = TempDir::new().expect("temp dir");  
    // ...  
}

Whitaker reports .expect() as if it were being called outside test-only code.

Example diagnostic:

error: Avoid calling expect on `std::result::Result<tempfile::TempDir, std::io::Error>` outside test-only code.  
  --> crates/weaverd/src/safety_harness/transaction/content_transaction_tests.rs:62:15  
   |  
62 |     let dir = TempDir::new().expect("temp dir");  
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
   |  
   = note: The call originates within function `content_transaction_rejects_lock_failure` which is not recognised as a test.

That diagnosis is wrong. The function is test code.

Root cause

Whitaker’s current test-detection logic appears to rely on patterns such as:

• #[test]
• well-known async test attributes such as #[tokio::test]
• possibly naming heuristics such as test_*

That misses rstest, because #[rstest] and related forms are procedural macro attributes that imply test semantics without necessarily exposing a plain #[test] attribute at the AST stage Whitaker inspects.

In other words, Whitaker currently treats “is this syntactically a standard Rust test?” as too close to “is this test-only code?”. Those are not equivalent.

Expected behavior

Whitaker should classify functions as test-only code when they are annotated with rstest test macros, including at least:

• #[rstest]

• #[rstest_parametrize]

It may also be worth considering whether supporting associated rstest patterns such as #[case::...] improves robustness, but the primary detection should sit on the function-level attributes.

For the example above, Whitaker should not emit no_expect_outside_tests or similar diagnostics.

Scope

This affects any Whitaker lint that needs to distinguish production code from test-only code, including but not limited to:

• no_expect_outside_tests
• no_unwrap_outside_tests
• any future lint that grants more latitude inside tests

It also matters for projects using:

• rstest
• rstest-bdd
• other proc-macro-based test frameworks with nonstandard test markers

Why Whitaker should handle this

It is reasonable for lint tools to recognize widely used test frameworks directly. Requiring every upstream test framework to emit custom tooling hints, or requiring every downstream project to configure special cases, creates unnecessary friction.

rstest is established enough that first-class support in Whitaker makes sense.

More importantly, the semantic question Whitaker is trying to answer is not “does this function have a literal #[test] attribute?” but “is this function test-only code?”. #[rstest] clearly satisfies that criterion.

Workarounds in the meantime

Projects can work around the issue, but all current workarounds are inferior to fixing detection in Whitaker.

Return Result from tests

#[rstest]  
#[case::syntactic(LockFailureKind::Syntactic, "syntax error")]  
fn content_transaction_rejects_lock_failure(  
    #[case] kind: LockFailureKind,  
    #[case] message: &str,  
) -> Result<(), String> {  
    let dir = TempDir::new().map_err(|e| format!("temp dir: {e}"))?;  
    // ...  
    Ok(())  
}

This avoids .expect(), but it changes test style and pushes projects toward ceremony they may not want.

Add redundant attributes

#[test]  
#[rstest]  
#[case::foo(1)]  
fn my_test(#[case] x: i32) { ... }

This is clumsy, may be fragile, and should not be necessary merely to satisfy a lint tool.

Add framework-specific configuration

Whitaker could support configurable test attributes, for example:

[no_expect_outside_tests]  
test_attributes = ["test", "rstest", "rstest_parametrize"]

That is better than nothing, but rstest is common enough that built-in support is preferable.

Suggested fix

Extend Whitaker’s existing “is this test-only code?” detection to recognize rstest attributes directly.

At minimum:

• treat a function annotated with #[rstest] as test-only
• treat a function annotated with #[rstest_parametrize] as test-only

If Whitaker already has shared test-detection logic used by multiple lints, this should go there rather than being implemented ad hoc in one lint.

It would also be sensible to structure the detection as a broader framework mechanism, so additional test frameworks can be supported consistently.

Acceptance criteria

• A function annotated with #[rstest] is recognized as test-only code.
• A function annotated with #[rstest_parametrize] is recognized as test-only code.
• no_expect_outside_tests does not fire for .expect() calls inside such functions.
• Existing support for #[test] and async test frameworks continues to work.
• The test-detection logic remains reusable across Whitaker lints.

Example regression test

#[rstest]  
#[case(1)]  
fn rstest_allows_expect_in_test_context(#[case] value: i32) {  
    let parsed = Some(value).expect("value should be present");  
    assert_eq!(parsed, 1);  
}

Whitaker should not report no_expect_outside_tests here.

Environment

• Whitaker issue observed against rstest 0.26.1
• Rust 1.75+
• Related Whitaker issue: Allow .unwrap_or_else(|| { panic!(...) }) under limited circumstances #188

Investigation in Whitaker

I reviewed the current test-detection path before assuming the recent Tokio work had dropped rstest support.

This does not look like a simple matcher regression. The shared test-like attribute registry in common/src/attributes/mod.rs still includes:

• rstest
• rstest::rstest
• case
• rstest::case

The HIR adapter in src/hir.rs still delegates to that shared matcher, and no_expect_outside_tests still uses that path in crates/no_expect_outside_tests/src/driver/mod.rs.

That suggests the recent Tokio work did not simply remove rstest from the recognised attribute list.

Likely culprit: hollow rstest regression coverage

The more likely problem is that Whitaker’s existing rstest coverage is too weak to catch a real regression.

The positive rstest UI fixture is:

• crates/no_expect_outside_tests/ui/pass_expect_in_rstest.rs

That fixture depends on the auxiliary proc-macro:

• crates/no_expect_outside_tests/ui/auxiliary/rstest.rs

The auxiliary macro simply prepends a literal #[test] to the item. That means the current UI test proves only that “a proc macro which emits #[test] is accepted”. It does not prove that real rstest is recognised correctly by Whitaker.

In other words, if native rstest detection were broken, this test could still pass.

Contrast with the recent Tokio work

The recent Tokio fix explicitly hardened coverage with a real example-based regression:

• crates/no_expect_outside_tests/src/lib_ui_tests.rs
• crates/no_expect_outside_tests/examples/pass_expect_in_tokio_test_harness.rs

That regression compiles a real #[tokio::test] example under --test, precisely because the earlier proc-macro fixture only covered token shape rather than the real lowering and harness path.

Whitaker currently lacks an equivalent end-to-end regression for real rstest usage.

Implication

The safest reading is:

• the recent Tokio work may have exposed the gap, but
• the underlying problem is more likely that Whitaker has a hollow rstest regression test which masks a real detection failure.

So the issue is probably not “Tokio support removed rstest from the matcher”. It is more likely “Whitaker does not currently prove that real rstest tests are classified as test-only code”.

Proposed follow-up

1. Add a real rstest example-based regression using the actual rstest crate rather than the current auxiliary proc-macro that injects #[test].

2. If that regression fails, inspect the lowered or HIR shape to determine whether rstest needs:

   • only direct source-level attribute recognition, or
   • an additional fallback path analogous to the Tokio harness-descriptor recovery.

3. Treat the current pass_expect_in_rstest fixture as insufficient on its own for future regressions.

[leynos]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• Add rstest_parametrize (bare and qualified forms) to the shared TEST_LIKE_PATHS registry in common/src/attributes/mod.rs
• Create a real rstest example file in crates/no_expect_outside_tests/examples/ that uses the actual rstest crate
• Wire the example into lib_ui_tests.rs following the established Tokio regression pattern with --test compilation
• Preserve the existing auxiliary-based UI fixture as complementary coverage for proc-macros that emit #[test]

Design Choices

Design Choice 1: The existing rstest registry entries are functional and the primary gap is hollow test coverage plus missing `rstest_parametrize`

Options Considered:

1. Assume architecture is sound; add registry entry and regression test
2. First audit HIR lowering behaviour for rstest attributes before adding tests

Chosen Option: 1

Rationale: The ticket's investigation suggests hollow coverage is the likely culprit; a real regression test will confirm or refute this hypothesis efficiently. If real rstest detection is broken at the HIR level, the new regression test will surface this and a follow-up investigation into harness-descriptor fallback paths will be required.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Extend the Test Attribute Registry

Add the missing rstest_parametrize attribute paths to the shared registry so all lints recognise this older rstest API form.

Add `rstest_parametrize` entries to `TEST_LIKE_PATHS`

Extend the canonical test-attribute registry to include the legacy rstest_parametrize macro.

• Update common/src/attributes/mod.rs to add two new entries to TEST_LIKE_PATHS: &["rstest_parametrize"] and &["rstest", "rstest_parametrize"]
• Place entries adjacent to existing rstest entries for logical grouping
• No other files require modification; all downstream detection flows through this registry

🤖 Prompt for AI agents

Extend the test-attribute registry in `common/src/attributes/mod.rs` to
recognise the legacy `rstest_parametrize` macro.

- Open `common/src/attributes/mod.rs` and locate `TEST_LIKE_PATHS`
- Add two new entries to `TEST_LIKE_PATHS`:
  - `&["rstest_parametrize"]`
  - `&["rstest", "rstest_parametrize"]`
- Place the new entries directly adjacent to the existing rstest entries for
logical grouping
- Do NOT modify any other files; all downstream detection flows through this
registry

Phase 2: Add Real rstest Regression Coverage

Create an example-based regression test using the actual rstest crate, mirroring the Tokio pattern established in lib_ui_tests.rs.

Task 1: Create the rstest example fixture

Add an example file that exercises .expect() inside real #[rstest] and #[rstest_parametrize] annotated functions.

• Create crates/no_expect_outside_tests/examples/pass_expect_in_rstest_harness.rs
• Include a function annotated with #[rstest] and #[case(...)] that calls .expect() on an Option or Result
• Include a function annotated with #[rstest_parametrize] (if rstest still exports this macro) that similarly calls .expect()
• Add a stub fn main() {} as required for Cargo examples
• The file must compile cleanly under --test with #![deny(no_expect_outside_tests)] without emitting diagnostics

Task 2: Wire the example into `lib_ui_tests.rs`

Add a test function that compiles the rstest example under --test mode with appropriate environment guards.

• Add a new test function rstest_example_compiles_under_test_harness to crates/no_expect_outside_tests/src/lib_ui_tests.rs
• Follow the Tokio test pattern: use whitaker::testing::ui::run_with_runner, run_test_runner, env_test_guard, and with_vars_unset
• Use Test::example(crate_name, "pass_expect_in_rstest_harness") and apply .rustc_flags(["--test"])
• Emit a descriptive panic message if the regression fails

Task 3: Verify dev-dependencies and feature flags

Confirm the crate configuration supports the new test.

• Check that rstest is already a dev-dependency in crates/no_expect_outside_tests/Cargo.toml (exploration confirms it is)
• Ensure rstest_parametrize is available from the rstest crate at the declared version; if deprecated or removed, document this and omit that test case
• No Cargo.toml changes expected unless version constraints require adjustment

🤖 Prompt for AI agents

Create a real rstest regression example and wire it into the UI test suite,
mirroring the established Tokio pattern.

**Task 1 — Create the example fixture**
- Create
`crates/no_expect_outside_tests/examples/pass_expect_in_rstest_harness.rs`
- Include `#![deny(no_expect_outside_tests)]` at the crate root
- Add a function annotated with `#[rstest]` and `#[case(...)]` that calls
`.expect()` on an `Option` or `Result`
- Add a function annotated with `#[rstest_parametrize]` (only if the macro is
still exported by the declared rstest version) that similarly calls `.expect()`
- Add a stub `fn main() {}` as required by Cargo for example targets
- The file must compile cleanly under `--test` without emitting any diagnostics

**Task 2 — Wire the example into `lib_ui_tests.rs`**
- Open `crates/no_expect_outside_tests/src/lib_ui_tests.rs`
- Add a new test function named `rstest_example_compiles_under_test_harness`
- Follow the Tokio test pattern exactly: use
`whitaker::testing::ui::run_with_runner`, `run_test_runner`, `env_test_guard`,
and `with_vars_unset`
- Reference the fixture via `Test::example(crate_name,
"pass_expect_in_rstest_harness")` and apply `.rustc_flags(["--test"])`
- Emit a descriptive panic message if the regression fails

**Task 3 — Verify dev-dependencies**
- Inspect `crates/no_expect_outside_tests/Cargo.toml` and confirm `rstest` is
already listed as a dev-dependency
- Confirm whether `rstest_parametrize` is exported at the declared version; if
it is deprecated or removed, document this in a code comment and omit that
specific test case
- Make no Cargo.toml changes unless version constraints require adjustment

Phase 3: Validate Existing Coverage

Ensure backwards compatibility and that existing tests continue to pass.

Run the full test suite

Execute the complete test suite to confirm no regressions.

• Run cargo test --workspace to verify all existing UI fixtures pass
• Confirm the existing ui/pass_expect_in_rstest.rs auxiliary-based test still passes
• Confirm the new rstest_example_compiles_under_test_harness test passes
• If the new test fails, document the failure mode for follow-up investigation into HIR attribute lowering

🤖 Prompt for AI agents

Validate the full test suite to confirm no regressions have been introduced.

- Run `cargo test --workspace` and verify all existing UI fixtures pass
- Confirm the existing `ui/pass_expect_in_rstest.rs` auxiliary-based test still
passes
- Confirm the new `rstest_example_compiles_under_test_harness` test passes
- If the new test fails, document the failure mode in a comment or note for
follow-up investigation into HIR attribute lowering

Research

Test-attribute recognition flows through a layered architecture: TEST_LIKE_PATHS in common/src/attributes/mod.rs defines the canonical registry; Attribute::is_test_like_with() in common/src/attributes/attribute.rs performs matching; src/hir.rs bridges HIR attributes to the domain model; and crates/no_expect_outside_tests/src/driver/mod.rs consumes this via has_test_like_hir_attributes. The Tokio regression pattern in lib_ui_tests.rs demonstrates how to test real proc-macro frameworks under --test compilation, which rstest lacks.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Extend the test-attribute registry in `common/src/attributes/mod.rs` to
recognise the legacy `rstest_parametrize` macro.

- Open `common/src/attributes/mod.rs` and locate `TEST_LIKE_PATHS`
- Add two new entries to `TEST_LIKE_PATHS`:
  - `&["rstest_parametrize"]`
  - `&["rstest", "rstest_parametrize"]`
- Place the new entries directly adjacent to the existing rstest entries for
logical grouping
- Do NOT modify any other files; all downstream detection flows through this
registry
===============================================================================

Task: 2

Create a real rstest regression example and wire it into the UI test suite,
mirroring the established Tokio pattern.

**Task 1 — Create the example fixture**
- Create
`crates/no_expect_outside_tests/examples/pass_expect_in_rstest_harness.rs`
- Include `#![deny(no_expect_outside_tests)]` at the crate root
- Add a function annotated with `#[rstest]` and `#[case(...)]` that calls
`.expect()` on an `Option` or `Result`
- Add a function annotated with `#[rstest_parametrize]` (only if the macro is
still exported by the declared rstest version) that similarly calls `.expect()`
- Add a stub `fn main() {}` as required by Cargo for example targets
- The file must compile cleanly under `--test` without emitting any diagnostics

**Task 2 — Wire the example into `lib_ui_tests.rs`**
- Open `crates/no_expect_outside_tests/src/lib_ui_tests.rs`
- Add a new test function named `rstest_example_compiles_under_test_harness`
- Follow the Tokio test pattern exactly: use
`whitaker::testing::ui::run_with_runner`, `run_test_runner`, `env_test_guard`,
and `with_vars_unset`
- Reference the fixture via `Test::example(crate_name,
"pass_expect_in_rstest_harness")` and apply `.rustc_flags(["--test"])`
- Emit a descriptive panic message if the regression fails

**Task 3 — Verify dev-dependencies**
- Inspect `crates/no_expect_outside_tests/Cargo.toml` and confirm `rstest` is
already listed as a dev-dependency
- Confirm whether `rstest_parametrize` is exported at the declared version; if
it is deprecated or removed, document this in a code comment and omit that
specific test case
- Make no Cargo.toml changes unless version constraints require adjustment
===============================================================================

Task: 3

Validate the full test suite to confirm no regressions have been introduced.

- Run `cargo test --workspace` and verify all existing UI fixtures pass
- Confirm the existing `ui/pass_expect_in_rstest.rs` auxiliary-based test still
passes
- Confirm the new `rstest_example_compiles_under_test_harness` test passes
- If the new test fails, document the failure mode in a comment or note for
follow-up investigation into HIR attribute lowering

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== TEST_LIKE_PATHS in common/src/attributes/mod.rs ==="
cat common/src/attributes/mod.rs 2>/dev/null || fd -g 'mod.rs' --full-path | xargs grep -l 'TEST_LIKE_PATHS' 2>/dev/null | head -3 | xargs cat

echo ""
echo "=== Check for pass_expect_in_rstest_harness example ==="
fd 'pass_expect_in_rstest_harness' 2>/dev/null

echo ""
echo "=== lib_ui_tests.rs ==="
fd 'lib_ui_tests.rs' 2>/dev/null | xargs cat

echo ""
echo "=== no_expect_outside_tests Cargo.toml ==="
fd 'Cargo.toml' --full-path | xargs grep -l 'rstest' 2>/dev/null | xargs cat

echo ""
echo "=== CHANGELOG or docs mentioning rstest_parametrize ==="
rg -rn 'rstest_parametrize' --type=md 2>/dev/null
rg -rn 'rstest_parametrize' --type=toml 2>/dev/null
rg -rn 'rstest_parametrize' 2>/dev/null | head -40

Length of output: 36385

---

🏁 Script executed:

#!/bin/bash
echo "=== Full TEST_LIKE_PATHS (grep context) ==="
rg -n 'TEST_LIKE_PATHS|rstest_parametrize|&\["n"\]|&\["case"\]' common/src/attributes/mod.rs

echo ""
echo "=== docs/users-guide.md lines mentioning rstest_parametrize ==="
rg -n -C3 'rstest_parametrize' docs/users-guide.md

echo ""
echo "=== pass_expect_in_rstest_harness.rs content ==="
cat crates/no_expect_outside_tests/examples/pass_expect_in_rstest_harness.rs

Length of output: 2300

---

@leynos, the issue is fully resolved — no further work is needed.

Here is the complete picture:

Registry (common/src/attributes/mod.rs) — Done
Both entries are present in TEST_LIKE_PATHS:

• Line 18: &["rstest_parametrize"]
• Line 19: &["rstest", "rstest_parametrize"]

Example fixture (crates/no_expect_outside_tests/examples/pass_expect_in_rstest_harness.rs) — Done
Exercises both the plain #[rstest] and the #[rstest] + #[case(...)] parametrised forms with real .expect() calls. The legacy #[rstest_parametrize] macro is intentionally absent — rstest 0.26.1 no longer exports it, so omitting it is correct.

Test wiring (lib_ui_tests.rs) — Done
The example is covered by two tests:

• example_compiles_under_test_harness (via #[rstest] #[case("pass_expect_in_rstest_harness", "rstest")]) — confirms the harness compiles cleanly under --test.
• rstest_expect_outside_tests_still_fails_in_non_harness_code — confirms the lint still fires for non-test rstest code.

Documentation (docs/users-guide.md) — Done
#[rstest_parametrize] and #[rstest::rstest_parametrize] appear at lines 354, 374–375, and 392–393, consistent with the registry entries. The issue can be closed.