mcpField
I
improving-frontend-coverage

improving-frontend-coverage

github.com/streamlitテスト・品質46.2k46 回インストール今日更新
リポジトリ

improving-frontend-coverage について

フロントエンドのユニットテストカバレッジを高めるエージェント向けスキルです。カバレッジ分析、テスト追加、反復検証、レビューを行います。

主な機能

  1. 01カバレッジに基づく対象選定
  2. 02振る舞いを重視したテスト選択
  3. 03カバレッジの反復検証
  4. 04簡素化とレビューの手順

活用シーン

  1. 01カバレッジの低いフロントエンド部品へのテスト追加
  2. 02UI 操作やエラー状態のテスト
  3. 03プロジェクトチェック前のカバレッジ向上

インストール

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

$npx skills add https://github.com/streamlit/streamlit --skill improving-frontend-coverage

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

詳細

フロントエンドカバレッジの改善

実際の価値をもたらす意味のあるテストを通じて、フロントエンドの単体テストカバレッジを約 0.2% 向上させます。

完全に自律的に動作してください — 確認を求めて停止したり一時停止したりしないでください。カバレッジ目標の 0.2% に到達するまで、反復（分析 → 実装 → 検証）を続けてください。何をテストすべきかについて曖昧さに遭遇した場合は、妥当な選択を行い、進めてください。

ワークフロー

ステップ 1: カバレッジ付きでテストを実行する

COVERAGE_JSON=1 make frontend-tests  # ~5 min

レポートは frontend/coverage/ に生成されます:

  • coverage-summary.json - ファイルごとのパーセンテージ（行、分岐、関数）
  • coverage-final.json - カバーされていない行番号を含む行レベルのデータ（s、f、b マップでヒット数が 0）

ステップ 2: 分析と優先順位付け

coverage-summary.json を読み、以下のファイルを見つけます:

  1. サイズが大きく、平均以下のカバレッジ（影響が大きい）
  2. lib/src/components/ のコアコンポーネント
  3. utils/src/ のユーティリティ関数

スキップ: カバレッジ >97%、自動生成、.d.ts、テストファイル。

ステップ 3: テストを実装する（サブエージェント内で）

優先順位付けされた各ファイルのテストを実装するサブエージェントを起動します。サブエージェントに以下を提供します:

  • coverage-final.json からの対象ファイルパスとカバーされていない行
  • ソース、既存のテストを読み、新しいテストを書くための指示
  • 以下のテスト選択ガイドライン

サブエージェントは以下を行う必要があります:

  1. ソースと既存のテストを読み、ギャップを理解する
  2. 以下のテストを書く: 条件付きレンダリング、イベントハンドラー、エラー状態、エッジケース、アクセシビリティ
  3. RTL のベストプラクティスに従う: ロール/ラベルでクエリし、実装ではなく振る舞いをテストする
  4. 新しいテストを実行して合格することを確認する: cd frontend && yarn test path/to/Component.test.tsx

ステップ 4: 検証と反復

cd frontend && yarn test path/to/Component.test.tsx  # Run new tests
COVERAGE_JSON=1 make frontend-tests                   # Measure progress

カバレッジが ≥0.2% 改善されるまでステップ 2〜4 を繰り返し、その後 make check を実行します。

ステップ 5: 簡素化、レビュー、フィードバックへの対応

すべてのテストが合格し、カバレッジ目標が達成されたら:

  1. simplifying-local-changes サブエージェントを実行し、コード変更をクリーンアップして簡素化します。完了を待ちます。
  2. reviewing-local-changes サブエージェントを実行し、変更をレビューします。完了を待ち、レビュー出力を読みます。
  3. レビューのフィードバックに対応します: 各推奨事項について、有効でコード品質を向上させる場合は実装し、該当しない場合や過剰な設計になる場合は簡単な理由を添えてスキップします。
  4. /checking-changes を実行し、変更後もすべてが合格することを確認します。

テストの選択

テストする: 条件付きレンダリング、ユーザーインタラクション、プロップのバリエーション、エラー処理、アクセシビリティ、エッジケース（null、空、最大値）。

テストしない: パススループロップ、スタイリング、ライブラリ内部、実装の詳細、すでに十分にカバーされているコード。

カバレッジ除外: 本当にテストが不要なコードには /* istanbul ignore next */ を控えめに使用します。常に理由を含めます（例: /* istanbul ignore next -- defensive */）:

  • jsdom で実行できないブラウザ固有の分岐（/* istanbul ignore next -- browser-only */）
  • 決して実行されるべきでない防御的フォールバック（/* istanbul ignore next -- defensive */）
  • フレームワークが必要とするボイラープレート（/* istanbul ignore next -- exhaustive */）

注意事項

  • 品質 > カバレッジ数値 - 実際のバグを捕捉しないテストはスキップする
  • テストファイル: <Component>.test.tsx として同じ場所に配置
  • テストを実装した後は /checking-changes を使用する

コメント

Markdown 対応