mcpField
D
detect-duplicate-test-cases

detect-duplicate-test-cases

github.com/testomatioテスト・品質16104 回インストール6 日前に更新
リポジトリ

detect-duplicate-test-cases について

プロジェクト内の手動・自動テストを調べ、重複や内容の重なりを検出して整理案を提示するスキルです。類似度に基づいて分類・グループ化し、ユーザーの承認後に統合、削除、維持を実行します。

主な機能

  1. 01手動・自動テストのスキャン
  2. 02タイトル、手順、アサーションの比較
  3. 034段階での検出結果の分類
  4. 04重複グループと提案のレポート
  5. 05承認後の統合・削除・維持
  6. 06テスト形式と追跡情報の保持

活用シーン

  1. 01大規模なテストリポジトリの重複整理
  2. 02意味やカバレッジが重なるテストの発見
  3. 03承認後に追跡情報を保って冗長テストを統合

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/testomatio/skills --skill detect-duplicate-test-cases

インストール後、Claude Code で/detect-duplicate-test-casesを入力して読み込まれたか確認します。

同梱ファイルreferences/DUPLICATE_INSTRUCTIONS.md

詳細

重複するテストケースの検出

ユーザーのプロジェクト内で重複するテストケースを検出し、整理方法を提案します。

ワークフロー

1. テストケースを収集する
  • リポジトリ内の手動テストケースと自動テストケースをすべて見つけます。
    • 手動:/tests/ 内の Markdown ファイル、.feature ファイル(Gherkin)。
    • 自動:*.spec.ts、*.test.js、*.cy.js など。
  • 各テストを解析し、タイトル、手順、期待される結果、タグ、スイートの場所を抽出します。
2. 重複を分析する

比較する前に、テストの内容を正規化します。

  • タイトルを小文字に変換します。
  • 句読点や書式の違いを取り除きます。
  • 可能な場合は、手順の表現を正規化します。
  • 意図の分析時には、フレームワークの構文(describe、Scenario、it など)を無視します。
  • パラメーター化された値(メールアドレス、ID、ユーザー名)は可変データとして扱います。

複数の類似性の指標を使ってテストを比較します。

  • タイトルの類似性。
  • 手順の類似性。
  • 期待される結果の類似性。
  • 前提条件またはセットアップ。
  • 共通するタグやメタデータ。
  • テストの場所またはスイートのコンテキスト。

./references/DUPLICATE_INSTRUCTIONS.md の採点ルールを使って、各ペアを採点します。 同じリファレンスで定義されている検出レベルに各ペアを分類します。

  • レベル 1:完全に重複。
  • レベル 2:意味的に重複。
  • レベル 3:重複箇所がある/サブセットのテスト。
  • レベル 4:冗長なバリエーション。

複数のテストが同じテスト意図を表す場合は、重複グループを作成します。 各グループには次の内容を含めます。

  • 関連するすべてのテスト。
  • 類似度スコア。
  • 検出レベル。
  • 正準テストの候補。
3. レポートを作成する

./references/DUPLICATE_INSTRUCTIONS.md のレポートテンプレートに従います。次の内容を含めます。

  • 概要統計(スキャンした総数、カテゴリ別に見つかった重複数)。
  • テストの詳細と場所を含む各重複グループ。
  • 類似度のパーセンテージ。
  • 各グループへの推奨事項(keep/merge/remove)。
  • 推奨するアクション。
4. アクションを実行する

アクションは、ユーザーが推奨事項を承認した後にのみ適用します。

  • マージ:重複するテスト、または類似度の高いテストをまとめて、1 つの正準テストにします。
    • フレームワークで使われている元のテスト構造(Gherkin、Markdown、Jest、Cypress など)を維持します。
    • 正準テストの主要なテスト ID を保持します。
    • すべての元テストのタグ、ラベル、メタデータを統合します(可能な場合は重複を取り除きます)。
    • 重要なアサーション、手順、期待される結果を保持します。
    • マージされた元のテストファイルまたは ID への参照を追加します。
  • 削除:重複または冗長なテストファイル、あるいはテスト項目を削除します。
    • 正準テストまたは置き換え先のテストがすでに存在することを確認します。
    • 削除したテストを記した参照を正準テストに追加します。
    • 固有の手順、タグ、またはカバレッジを含むテストは削除しないでください。
  • 維持:両方のテストを残し、その関連性を記録します。
    • 関連するテスト間に相互参照の注記を追加します。
    • 両方を残す理由(例:環境、データセット、またはカバレッジの違い)を示します。

保持ルール

テストをマージまたは書き換える際は、次の内容を保持します。

  • テスト ID:正準テストの ID を維持し、マージした ID を参照します。
  • タグ/ラベル:関連するすべてのタグを保持し、統合します。
  • フレームワークの構造:元の形式(例:Scenario、describe/it、Markdown のセクション)を維持します。
  • ファイル構成:既存のテストディレクトリの規則を維持します。
  • トレーサビリティのメタデータ:要件、イシュー、チケットへのリンクがある場合は保持します。

テストを書き換える際に、フレームワークの構文を壊したり、トレーサビリティのメタデータを削除したりしないでください。

コメント