create-tests-extract

Extract inline Rust test modules into adjacent files while preserving private-item access.

4|3|Updated Mar 15, 2026
One-click install
npx skills add https://github.com/ulpi-io/skills --skill create-tests-extract
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-tests-extract
Source: https://github.com/ulpi-io/skills/tree/main/create-tests-extract
Command: npx skills add https://github.com/ulpi-io/skills --skill create-tests-extract

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill removes bulky inline Rust test blocks from production files without weakening test coverage, changing private-item access, or introducing unnecessary production refactoring.

Core Features & Use Cases

  • Safe Extraction Boundaries: Chooses adjacent test modules instead of top-level integration tests when private access matters.
  • Semantic Preservation: Keeps test names, attributes, helpers, visibility, imports, and effective coverage intact.
  • Focused Verification: Runs the narrowest relevant test suite and checks for compilation, warning, and visibility regressions.
  • Use Case: Use it when a Rust source file contains a large cfg-test module that should be moved into an adjacent test file while preserving access to private implementation details.

Quick Start

Ask the skill to extract the bulky inline tests from the specified Rust source file into the smallest safe adjacent test module and verify the moved suite.

Frequently Asked Questions about create-tests-extract

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I move inline Rust tests to a separate file without losing private item access?

To extract inline Rust tests without losing private item access, move the cfg-test module into an adjacent test file. This preserves private visibility by keeping the extracted tests within the same module hierarchy and maintaining coverage.

What is the best way to organize bulky Rust unit tests in production source files?

Organizing bulky Rust unit tests involves extracting large inline test blocks into adjacent files. This module layout improvement removes clutter from production code while preserving test names, attributes, and helper behavior.

Can I extract a Rust cfg-test module without breaking my existing test coverage?

Yes, extracting a Rust cfg-test module preserves existing test coverage by keeping helper behavior and attributes intact. The process requires minimal module wiring and narrow post-extraction test validation to ensure no regressions.

Does moving Rust unit tests to adjacent files require refactoring production code?

Moving Rust unit tests to adjacent files does not require unnecessary production refactoring. The extraction process focuses on minimal module wiring and preserving visibility, keeping the production source logic untouched while relocating the tests.

Why do my Rust tests fail after moving them out of the main source file?

Rust tests fail after extraction if private-item access is broken or module wiring is incorrect. Safe extraction uses adjacent test modules instead of top-level integration tests to maintain private implementation access and prevent compilation regressions.

When should I use adjacent test modules instead of top-level integration tests for Rust?

Use adjacent test modules instead of top-level integration tests when private access to implementation details matters. Adjacent modules preserve visibility and helper behavior, ensuring extracted inline tests maintain their original coverage scope.