create-tests-extract

重点是提升可读性，同时不改变语义。

不可妥协的规则：

1. 移动任何内容前，完整阅读源文件及其中的内联测试。
2. 保留原有的可见性和辅助项访问模型。
3. 需要访问私有项时，优先选择相邻测试模块，而不是集成测试。
4. 生产代码只做模块接线所必需的改动。
5. 提取后运行范围最小的相关测试。

create-tests-extract

输入

• $request：源文件、模块或清理目标

目标

将庞大的内联测试移至相邻文件，同时保留：

• 相同的实际测试覆盖率
• 必要时对私有项的相同访问权限
• 更清晰的生产文件

步骤 0：阅读并分类测试块

检查：

• 生产文件
• 内联测试模块
• 仅供测试使用的辅助函数或 fixture
• 测试是否依赖 super::* 或私有模块项

如果该文件属于 Rust crate，在更改模块布局前，先参考 rust 了解惯例。

成功标准：将测试归类为本地内联测试、相邻模块测试或真正的集成测试候选项。

步骤 1：选择最小且安全的提取边界

优先选择：

• foo.rs + #[cfg(test)] mod foo_tests; + foo_tests.rs
• 或目录模块中的 foo/mod.rs + tests.rs

除非测试确实应成为公共 API 集成测试，否则避免将其放入顶层 tests/。

成功标准：新的布局保留预期的可见性模型。

步骤 2：提取时不改变语义

移动测试时：

• 添加最精简的 #[cfg(test)] mod ...; 接线
• 在需要时保留 use super::*; 或等效导入
• 保留测试名称和属性
• 将仅供测试使用的辅助项与需要它们的测试套件一并移动

不要重命名测试，也不要重构生产模块，除非提取确有需要。

成功标准：移动后的测试仍能在相同的实际上下文中编译。

步骤 3：验证移动后的测试套件

提取后：

• 运行范围最小的相关测试
• 检查警告或可见性回归
• 确认生产文件明显更易于浏览

成功标准：新的布局通过验证且保留原有行为。

防护原则

• 不要意外地将私有单元测试变成仅限公共 API 的集成测试。
• 不要移动仍能提升可读性的少量说明性内联测试。
• 不要将重构范围扩大到所请求的提取之外。
• 不要为了缩短生产文件而删除 fixture 或辅助覆盖。

输出约定

报告：

1. 创建或修改的文件
2. 选择的提取布局
3. 有意保留为内联的测试
4. 移动后运行的验证