Expand description
Recognising units that exist to test other code.
Test suites repeat themselves on purpose. The same fixture is built, the same call is made and the same assertion is written across dozens of cases, because a test that shares its setup with its neighbours stops being readable on its own. Reporting that repetition next to duplication in the code under test buries the latter: on a well-tested project most clone groups live in the suite.
So the fact is recorded here and left to presentation to act on, exactly as
crate::boilerplate classification is. A unit marked as test code is
still parsed, still compared and still grouped; only where its group lands
in a report changes, and it can always be shown.
§What counts
An explicit marker in the source is the strongest evidence: whatever the language’s own test tooling makes an author write to declare a case. In Rust that is an attribute; in C and C++ it is the macro the framework defines, which stands where a function’s return type and name would. A unit inside a marked container — a module compiled only for tests — is test code too, since it exists to serve the cases in it.
Paths are also evidence, not a suppression rule. The conventional test
paths in DEFAULT_TEST_PATHS classify otherwise unmarked helpers as test
code so presentation can rank them below production findings without hiding
them. The caller may replace or disable those patterns. Reports retain
whether a group was recognised by a marker or a path, and a marker wins
whenever both apply, so the two sources of evidence never disagree
silently.
§A container the file does not hold
A Rust module can be declared in one file and written in another:
#[cfg(test)] mod tests; beside a tests.rs, or a tests/ directory of
them. The marker is on the declaration, so nothing in the file it governs
carries it, and reading each file alone leaves every helper in that tree
looking like ordinary code — a suite of a hundred cases can come back
unrecognised because its #[test] functions were the only ones ever
marked.
declared_test_modules closes that by following the declaration to the
file it names, and onwards through whatever that file declares in turn.
This is not the directory convention arriving by another route: what is
read is still the author’s own #[cfg(test)], and a tests directory
nobody declared that way is still ordinary code. It needs the whole file
set at once, which is why it sits apart from is_marked rather than
inside it.
Structs§
- Module
File - One file, as module resolution needs to see it.
Enums§
- Test
Code Evidence - Why a unit or group is recognised as test code.
Constants§
- DEFAULT_
TEST_ PATHS - Conventional paths that contain test code.
- TEST_
CODE_ VERSION - Version of the test-code recognition rules.
Functions§
- aggregate_
evidence - Aggregate member evidence for one group.
- declared_
test_ modules - Which of these files are the body of a module the tree declares test-only.
- is_
marked - Whether a node’s own leading tokens mark it as test code.