mcpField
C
create-tests-extract

create-tests-extract

github.com/ulpi-ioDevelopment5113 installsUpdated 9w ago
Repository

About create-tests-extract

A coding skill for moving bulky inline Rust tests into adjacent files while preserving coverage, private-item access, and behavior. It guides developers through choosing an extraction boundary, making minimal module changes, and validating the result.

Key features

  1. 01Classifies inline tests and access needs
  2. 02Chooses a minimal extraction layout
  3. 03Preserves test names, helpers, and visibility
  4. 04Runs focused tests after extraction
  5. 05Reports modified files and validation

Use cases

  1. 01Extracting large test modules from Rust source files
  2. 02Keeping unit tests able to access private module items
  3. 03Cleaning up production files without broad refactoring

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/ulpi-io/skills --skill create-tests-extract

After installing, type/create-tests-extractin Claude Code to confirm it loaded.

Details

From the project README
The point is readability without semantic drift.

Non-negotiable rules:

  1. Read the source file and its inline tests fully before moving anything.
  2. Preserve the original visibility and helper access model.
  3. Prefer adjacent test modules over integration tests when private access matters.
  4. Change production code only as much as module wiring requires.
  5. 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.rs for 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:

  1. files created or modified
  2. extraction layout chosen
  3. any tests intentionally left inline
  4. validation run after the move

Comments

Markdown supported