create-tests-extract
Non-negotiable rules:
- Read the source file and its inline tests fully before moving anything.
- Preserve the original visibility and helper access model.
- Prefer adjacent test modules over integration tests when private access matters.
- Change production code only as much as module wiring requires.
- Run the narrowest relevant tests after extraction.
create-tests-extract
Inputs
$request: Source file, module, or cleanup goal
Goal
Move bulky inline tests into adjacent files while keeping:
- the same effective test coverage
- the same access to private items where needed
- a clearer production file
Step 0: Read and classify the test block
Inspect:
- the production file
- the inline test module
- helper functions or fixtures used only by tests
- whether the tests depend on
super::*or private module items
If the file belongs to a Rust crate, use rust for conventions before changing the module layout.
Success criteria: The tests are classified as local-inline, adjacent-module, or true integration candidates.
Step 1: Choose the smallest safe extraction boundary
Prefer:
foo.rs+#[cfg(test)] mod foo_tests;+foo_tests.rs- or
foo/mod.rs+tests.rsfor directory modules
Avoid pushing tests into top-level tests/ unless they genuinely should become public-API integration tests.
Success criteria: The new layout preserves the intended visibility model.
Step 2: Extract without semantic drift
When moving the tests:
- add the minimal
#[cfg(test)] mod ...;wiring - keep
use super::*;or equivalent imports when needed - preserve test names and attributes
- move test-only helpers with the suite that needs them
Do not rename tests or restructure production modules unless the extraction requires it.
Success criteria: The moved tests still compile in the same effective context.
Step 3: Verify the moved suite
After extraction:
- run the narrowest relevant tests
- check for warnings or visibility regressions
- verify the production file is materially easier to scan
Success criteria: The new layout passes and preserves behavior.
Guardrails
- Do not turn private unit tests into public-only integration tests by accident.
- Do not move tiny, explanatory inline tests that still improve readability where they are.
- Do not broaden the refactor beyond the requested extraction.
- Do not drop fixtures or helper coverage just to shorten the production file.
Output Contract
Report:
- files created or modified
- extraction layout chosen
- any tests intentionally left inline
- validation run after the move