Module test_paths 

Shared classification of test paths.

Two sets of paths exist:

• Test code holds the tests: specs, test directories and end-to-end suites.
• Test support helps the tests: mocks, fixtures and snapshots.

is_test_code_path matches test code only. Use it when the question is “does a test exist” or “did a test change”: audit test adjacency, audit test-weakening signals and similar-code related tests.

is_test_path matches test code and test support. Use it when the question is “is this production code”: health hotspots, the human check split, orientation and the audit branching split.

The match is mostly syntactic and ASCII case-insensitive. A directory segment matches by its full name, and a file-name marker matches only in the last segment. Both / and \ separate segments, so the verdict does not depend on the platform.

Two rules also read the file system below the project root, because the path alone is not sufficient:

• A .cy. file is a Cypress spec only when it is a script file below a cypress directory, or below a directory that holds a Cypress config or a cypress directory. .cy. is also the Welsh language code, so src/i18n/strings.cy.ts in a project without Cypress is not a test.
• A spec or specs directory holds tests only at a test root: the project root, a package root (a directory with a package.json), or a directory with a src or lib directory next to the spec directory. A src/spec/ module is production code.

Functions

is_test_code_path

Whether a project-relative path is test code. Test support (mocks, fixtures and snapshots) does not match, except below a test directory.

is_test_code_path_str

Whether a project-relative path string is test code.

is_test_path

Whether a project-relative path is test code or test support.

is_test_path_str

Whether a project-relative path string is test code or test support.