create-tests-extract

読みやすさを高めつつ、意味を変えないことが重要です。

譲れないルール：

1. 移動する前に、ソースファイルとインラインテストを最後まで読んでください。
2. 元の可視性とヘルパーへのアクセス方法を維持してください。
3. プライベートな項目へのアクセスが重要な場合は、統合テストより隣接するテストモジュールを優先してください。
4. モジュールの接続に必要な範囲に限り、本番コードを変更してください。
5. 抽出後に、関連するテストのうち最小範囲のものを実行してください。

create-tests-extract

入力

• $request：ソースファイル、モジュール、またはクリーンアップの目的

目標

次の点を維持しながら、大きなインラインテストを隣接するファイルに移動します。

• 実質的に同じテストカバレッジ
• 必要に応じたプライベート項目への同じアクセス
• より見通しのよい本番ファイル

ステップ 0：テストブロックを読み、分類する

次の内容を確認します。

• 本番ファイル
• インラインテストモジュール
• テスト専用のヘルパー関数やフィクスチャ
• テストがsuper::*やプライベートなモジュール項目に依存しているかどうか

ファイルがRustクレートに属する場合は、モジュール構成を変更する前に規約として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のみを対象とする統合テストにしないでください。
• その場に置くことで読みやすさが向上する、小規模で説明的なインラインテストは移動しないでください。
• 依頼された抽出を超えてリファクタリングの範囲を広げないでください。
• 本番ファイルを短くするためだけに、フィクスチャやヘルパーのカバレッジを削除しないでください。

出力仕様

次の内容を報告してください。

1. 作成または変更したファイル
2. 選択した抽出レイアウト
3. 意図的にインラインに残したテスト
4. 移動後に実施した検証