Module collection 

Which of an attempt’s changed test files the run actually collected: a test that never ran is evidence of nothing.

Each test file the attempt added or changed — a test path by convention that defines tests by its toolchain’s markers — is decided, in order, by the toolchain’s static rule (it alone can prove a file is never collected), the check’s fresh JUnit report, and the runner’s own listing (or the check’s list command). What none of them decides is unknown: it never passes.

Modules

junit_map

Test ids (a JUnit report’s classname::name, a listing’s lines) mapped back to the file they come from, per toolchain.

listing

The runners’ own listings: which tests they would run, asked only when the static rule and the JUnit report leave a file undecided. Each runs like a check — sandboxed, scrubbed environment, the check’s deadline.

runner

The listing a check’s own run implies: built from the argv of a fast check that runs the toolchain — its selectors, filters and packages kept — so a test counts only if a check the verdict rests on would run it. No check runs the toolchain: there is no listing, and the file is unknown.

static_cfg

The collection rules as the project configures them, read from static files only: Cargo manifests, pytest’s ini/toml sections, package.json and JSON runner configs, go.mod. A configuration that is code (a vitest.config.ts) is not evaluated: the rule is unknown there and the runner’s listing decides.

Structs

Input

What the judge hands the collection check.

Functions

judge

Decides every judged file of the attempt; None when it changed none.

judged_files

The attempt’s changed files that are judged: test paths by convention that define tests, not deleted, not build output or dependencies, not benchmarks or examples.

statically_refused

Why the runner would never collect a new file at path with content, by the static rule alone (None: it may be collected, or the rule is not known statically). For placing new test files.