vulture whitelists Test* classes and test_* methods when any component of the path looks like a test — not only the filename.
neutral/fragment.py -> 3 findings
neutral/test_thing.py -> 1 finding
test_suite/fragment.py -> 1 finding <-- the directory alone is enough
This is correct behaviour: a test runner will call those names, so they are reachable. It is simply undocumented, and the directory-level trigger is surprising.
It cost this project an afternoon. Our parity suite reported a mismatch against real numpy test files; the first hypothesis was the filename, and the actual cause turned out to be that pytest's own tmp_path fixture creates directories named after the test function — so even the "neutral" control was being whitelisted.
The task
Open an issue (or better, a docs PR) on jendrikseipp/vulture noting that the whitelist triggers on any path component, with the three-line reproduction above.
Pinned here by test_vulture_output_depends_on_the_path in tests/conformance/test_engine_parity.py.
vulture whitelists
Test*classes andtest_*methods when any component of the path looks like a test — not only the filename.This is correct behaviour: a test runner will call those names, so they are reachable. It is simply undocumented, and the directory-level trigger is surprising.
It cost this project an afternoon. Our parity suite reported a mismatch against real numpy test files; the first hypothesis was the filename, and the actual cause turned out to be that pytest's own
tmp_pathfixture creates directories named after the test function — so even the "neutral" control was being whitelisted.The task
Open an issue (or better, a docs PR) on jendrikseipp/vulture noting that the whitelist triggers on any path component, with the three-line reproduction above.
Pinned here by
test_vulture_output_depends_on_the_pathintests/conformance/test_engine_parity.py.