Skip to Content
品質コマンド/moai coverage

/moai coverage

テストカバレッジを分析し、ギャップを特定し、不足しているテストを自動生成するコマンドです。

一言まとめ: /moai coverage は「テストギャップハンター」です。言語別カバレッジツールで 正確に測定 し、優先度別に 不足テストを自動生成 します。

スラッシュコマンド: Claude Code で /moai:coverage と入力すると、このコマンドを直接実行できます。/moai だけ入力すると、利用可能なすべてのサブコマンドの一覧が表示されます。

概要

テストカバレッジを向上させるには、まずどこが不足しているかを知る必要があります。/moai coverage は言語別の専用ツールでカバレッジを正確に測定し、リスク度に応じてギャップを優先順位で分類し、不足しているテストを自動生成します。

quality.yamldevelopment_mode 設定に応じて、TDD または DDD 方式のテストを生成します。

使用法

# プロジェクト全体のカバレッジ分析とテスト生成 > /moai coverage # カバレッジ目標 85% で分析 > /moai coverage --target 85 # 特定ファイルのみ分析 > /moai coverage --file src/auth/ # レポートのみ生成 (テスト生成なし) > /moai coverage --report # 未カバー行のみ表示 > /moai coverage --uncovered # クリティカルパスのみに集中 > /moai coverage --critical

サポートされるフラグ

フラグ説明
--target Nカバレッジ目標パーセント (デフォルト: quality.yaml の test_coverage_target)/moai coverage --target 85
--file PATH特定ファイルまたはディレクトリのみ分析/moai coverage --file src/auth/
--reportレポートのみ生成、テスト生成なし/moai coverage --report
--package PKG特定パッケージ (Go) またはモジュールのみ分析/moai coverage --package pkg/api
--uncovered未カバーの行/関数のみ表示/moai coverage --uncovered
--criticalクリティカルパス (高い fan_in、パブリック API) に集中/moai coverage --critical

—target フラグ

カバレッジ目標を指定します。未指定の場合、quality.yamltest_coverage_target 値を使用します (デフォルト: 85%):

# 90% カバレッジ達成目標 > /moai coverage --target 90

—report フラグ

テストを生成せず、ギャップ分析レポートのみ出力します:

> /moai coverage --report

現在の状態を把握したい場合に便利です。

—critical フラグ

P1 (パブリック API、高い fan_in) および P2 (ビジネスロジック、エラーハンドリング) のみに集中します:

> /moai coverage --critical

実行プロセス

/moai coverage は5段階で実行されます。

Phase 1: カバレッジ測定

言語別の専用ツールで正確なカバレッジを測定します:

言語カバレッジツール実行コマンド
Gogo test + covergo test -coverprofile=coverage.out -covermode=atomic ./...
Pythonpytest-cov または coveragepytest --cov --cov-report=json
TypeScript/JavaScriptvitest または jestvitest run --coverage
Rustcargo-llvm-covcargo llvm-cov --json

測定結果:

  • 全体カバレッジパーセント
  • ファイル別カバレッジパーセント
  • 関数別カバレッジデータ (カバー済み/未カバー行)
  • ブランチカバレッジ (利用可能な場合)

Phase 2: ギャップ分析

カバレッジターゲット未達のファイルを特定し、優先順位で分類します:

優先度条件説明
P1 (クリティカル)パブリック API 関数、fan_in >= 3、@MX:ANCHOR最優先テスト必要
P2 (高)ビジネスロジック、エラーハンドリングパスビジネス影響の大きいコード
P3 (中)内部ユーティリティ、ヘルパー関数ターゲット未達時テスト必要
P4 (低)生成コード、設定、単純な getter/setterターゲットから除外可能

Phase 3: テスト生成

quality.yamldevelopment_mode に応じて異なる方法でテストを生成します:

モードテスト方式説明
TDDRED-GREEN-REFACTOR失敗するテストを先に作成して検証
DDD特性化テスト既存の動作をキャプチャするテスト作成

テスト生成順: P1 → P2 → P3 → P4 スキップ

各ギャップに対して:

  • テーブルドリブンテスト (Go) またはパラメータ化テスト (Python/TS)
  • エッジケースとエラーシナリオを含む
  • コードベースの既存テストパターンに従う
  • ファイル命名規則を遵守 (*_test.go, *.test.ts, test_*.py)

Phase 4: 検証

テスト生成後:

  • 完全なテストスイートを実行してリグレッションがないことを確認
  • カバレッジを再測定して改善を確認
  • 前後のカバレッジパーセントを比較
  • ターゲット達成を確認

Phase 5: レポート

## カバレッジレポート ### Before: 72.5% -> After: 88.3% ### ターゲット: 85% - 達成 ### 生成されたテスト: 8個 - auth_test.go: TestAuthenticateUser (P1 ギャップカバー) - auth_test.go: TestValidateToken (P1 ギャップカバー) - handler_test.go: TestErrorHandling (P2 ギャップカバー) ### パッケージ別カバレッジ | パッケージ | Before | After | ターゲット | 状態 | |-----------|--------|-------|-----------|------| | pkg/api | 70% | 88% | 85% | PASS | | pkg/core | 45% | 82% | 85% | FAIL | ### 残りのギャップ - pkg/core: 3% 不足 (2関数が未カバー)

エージェント委任チェーン

エージェントの役割:

エージェント役割主な作業
MoAI オーケストレーターワークフロー調整、ユーザーインタラクションレポート出力、次のステップ案内
expert-testing測定、分析、生成、検証の専任カバレッジ測定、ギャップ分析、テスト作成、検証

よくある質問

Q: どのカバレッジツールが使用されますか?

プロジェクト言語に適した標準ツールが自動選択されます。Go は go test -cover、Python は pytest-cov、TypeScript は vitest または jest のカバレッジ機能を使用します。

Q: 生成されたテストの品質はどうですか?

コードベースの既存テストパターンを分析して一貫したスタイルでテストを作成します。テーブルドリブンテスト、エッジケース、エラーシナリオを含みます。

Q: カバレッジターゲットが達成できない場合は?

残りのギャップリストとともに追加テスト生成オプションが提示されます。P4 (低優先度) ギャップはスキップされるため、100% 達成は不可能な場合があります。

Q: 特定ファイルをカバレッジ測定から除外できますか?

quality.yamlcoverage_exemptions 設定で除外できます。ただし、除外率はデフォルトで 5% に制限されています。

関連ドキュメント

Last updated on