Repository navigation
no_expect_outside_tests fires on src/**/tests/*.rs modules declared #[cfg(test)] from a parent file #417
Description
Three repositories on the rolling suite fail their Lint gate on main with no_expect_outside_tests reported inside test modules:
- ddlint: src/parser/tests/helpers.rs:139, rules/aggregations.rs:16, rules/body_terms.rs:17 (main CI run 31733282790, job 94558684996; ddlint Chore(deps): Bump thiserror from 2.0.18 to 2.0.19 #313)
- mriya: src/sync/tests/remote.rs:30, streaming.rs:16 (run 31811852667, job 94804119628; mriya Chore(deps): bump DavidAnson/markdownlint-cli2-action from 20.0.0 to 22.0.0 #85)
- tei-rapporteur: dozens across tei-py/src/tests/ and tei-py/src/test_support/tests/ (run 33486857694, job 99788854208; tei-rapporteur Implemented 3.4.6: installer metrics download-vs-build and total time #148)
In each case the file lives under a tests/ directory beneath src/ and is pulled in by a #[cfg(test)] mod declaration in a parent file, so the lint's view of the file does not see the cfg(test) attribute and treats it as production code. Axinite hit the same shape on 2026-09-05 with cfg(test) helper functions (#356 made them fallible to satisfy the lint).
Expected: the lint recognises a module as test-only when its declaring mod item carries #[cfg(test)] (or the file sits under a tests/ directory beneath src/), or the suite documents the required layout and the estate's repositories are moved to it.
Found during the mutation-cargo.yml repin sweep (2026-09-05/06); all three lanes were red before the sweep touched them.
Activity
leynos commentedon Sep 6, 2026
Closing: this is correct lint behaviour, not a defect.
House policy, in the
addressing-whitaker-findingsskill (~/.claude/skills/addressing-whitaker-findings/SKILL.md, underno_expect_outside_testsandno_unwrap_or_else_panic): fixture and helper functions are not tests. A fixture arranges state; arrangement can fail, so it must returnResultand propagate errors. Only the test body may unwrap, because there a failure is the test verdict.Every site listed here is a helper, not a test body. ddlint's
parse_single_iteminsrc/parser/tests/helpers.rsis the clearest case: it is a plainfnthat other tests call. The lint reporting it is the suite doing its job, and exempting it would have removed the policy's teeth inside exactly the code the policy is about. #418 is closed unmerged for that reason.The expected behaviour proposed above, recognising a module as test-only when its declaring
moditem carries#[cfg(test)], would have that effect, so it is not the fix. The fix is in the three repositories: convert the reported helpers to returnanyhow::Resultor the domain error, with tests consuming via?or unwrapping in the body. One pull request each, following the skill's playbook and its clippy interactions (panic_in_result_fndeniesassert!inResult-returning tests;shadow_reusefires onlet x = x?).Two findings from the investigation are worth keeping on the record even though the change is abandoned.
#[cfg(test)]does not reach a late lint pass as written: the compiler evaluates it during expansion and leaves a parsedCfgTraceattribute, andis_cfg_test_attributeopens by rejecting every parsed attribute. That detection has therefore matched nothing since the attribute became parsed. Under the policy it should not exempt helpers anyway, so whether to remove the dead branch or document it is a separate question.Every
cfg(test)fixture in the suite is vacuous: each puts the call inside a#[test]function, so it passes on the test attribute rather than on module ancestry, and a fixture not built with--testhas its module stripped before the lint runs. Worth knowing for whoever next touches that area.