What happened
A test that created a directory named "..." via path.mkdir() failed on Windows CI. On Windows, "..." is interpreted as parent directory traversal (../..), so mkdir() raised FileExistsError because the resolved path already existed. Similarly, directory names like "project." (trailing dot) are silently stripped by Windows, leading to unexpected behaviour.
Root cause
The test created real filesystem directories to test a pure string-processing function (get_project_name_from_dir()). The function only reads the .name attribute of a Path object and never accesses the filesystem. By unnecessarily coupling the test to real directory creation, the test became sensitive to OS-specific path normalisation rules that are irrelevant to the logic under test.
Generalised principle
When testing pure logic that only inspects path metadata (e.g. .name, .suffix, .parent) without touching the filesystem, use synthetic Path or PurePosixPath objects instead of creating real directories. This avoids cross-platform failures caused by OS-specific path restrictions — especially on Windows, where certain characters and patterns (leading/trailing dots, reserved names like CON, NUL, etc.) are invalid or silently normalised in real paths.
Recommended action
- Skill update: Update the
usethis-python-test skill to include guidance: "When the code under test only reads path metadata (.name, .suffix, .parent) and does not access the filesystem, prefer PurePosixPath or direct usethis_config.set(project_dir=...) with synthetic paths instead of creating real directories. This avoids Windows-specific path restrictions causing test failures."
- Scan the codebase for violations of this principle and fix
What happened
A test that created a directory named
"..."viapath.mkdir()failed on Windows CI. On Windows,"..."is interpreted as parent directory traversal (../..), somkdir()raisedFileExistsErrorbecause the resolved path already existed. Similarly, directory names like"project."(trailing dot) are silently stripped by Windows, leading to unexpected behaviour.Root cause
The test created real filesystem directories to test a pure string-processing function (
get_project_name_from_dir()). The function only reads the.nameattribute of aPathobject and never accesses the filesystem. By unnecessarily coupling the test to real directory creation, the test became sensitive to OS-specific path normalisation rules that are irrelevant to the logic under test.Generalised principle
When testing pure logic that only inspects path metadata (e.g.
.name,.suffix,.parent) without touching the filesystem, use syntheticPathorPurePosixPathobjects instead of creating real directories. This avoids cross-platform failures caused by OS-specific path restrictions — especially on Windows, where certain characters and patterns (leading/trailing dots, reserved names likeCON,NUL, etc.) are invalid or silently normalised in real paths.Recommended action
usethis-python-testskill to include guidance: "When the code under test only reads path metadata (.name,.suffix,.parent) and does not access the filesystem, preferPurePosixPathor directusethis_config.set(project_dir=...)with synthetic paths instead of creating real directories. This avoids Windows-specific path restrictions causing test failures."