platform-apex-test-run

platform-apex-test-run：Salesforce のテスト実行とカバレッジ分析

Apex のテスト実行と失敗分析が必要な場合に、このスキルを使用します。対象となるのは、テストの実行、カバレッジの確認、失敗の解釈、カバレッジの改善、Salesforce コードに対する規律あるテスト修正ループの管理です。

このスキルが担当するタスク

次の作業では platform-apex-test-run を使用します。

• sf apex run test のワークフロー
• Apex の単体テストの失敗
• コードカバレッジ分析
• 未カバー行と不足しているテストシナリオの特定
• Apex コードに対する体系的なテスト修正ループ

次の場合は、別のスキルに委任します。

• 本番用 Apex の作成またはリファクタリング → platform-apex-generate スキル
• Agentforce エージェントのテスト → agentforce-test スキル
• Jest を使用した LWC のテスト → experience-lwc-generate

---

事前に収集する必要があるコンテキスト

次の情報を尋ねるか、推測してください。

• 対象の組織エイリアス
• 希望するテスト範囲：単一クラス、特定のメソッド、スイート、またはローカルテスト
• カバレッジのしきい値に関する要件
• ユーザーが求めているのは診断のみか、テスト修正ループか
• 関連するテストデータファクトリーがすでに存在するか

---

推奨ワークフロー

1. テスト範囲を特定する

次を特定します。

• 既存のテストクラス
• 対象の本番クラス
• テストデータファクトリー／セットアップヘルパー

2. まず、必要最小限のテストセットを実行する

失敗をデバッグするときは、最初は範囲を絞り、修正が安定してから範囲を広げます。

3. 結果を分析する

次の点に注目します。

• 失敗したメソッド
• 例外の種類とスタックトレース
• 未カバー行／カバレッジの弱い領域
• 失敗の原因がテストデータの不備、脆弱なアサーション、本番ロジックの不具合のどれに当たるか

4. 規律ある修正ループを実行する

コードまたはテストの品質に問題がある場合：

• 必要に応じて、コードの修正を platform-apex-generate スキルに委任する
• テストを追加または改善する
• 広範な回帰テストの前に、対象を絞ったテストを再実行する

5. 意図的にカバレッジを改善する

次のケースをカバーします。

• 正常系
• 異常系／例外系
• 一括処理（適切な場合は 251 件以上のレコード）
• 関連する場合はコールアウトまたは非同期処理のケース

---

重要なルール

ルール	理由
デフォルトで SeeAllData=false を使用する	テストの分離を確保し、組織固有のデータへの依存を防ぎます
すべてのテストで意味のある結果をアサートする	アサーションのないテストは何も証明せず、誤った安心感を与えます
251 件以上のレコードで一括処理の動作をテストする	プロセスは 200 件単位でバッチ処理されるため、251 件で境界をまたぎます
明確さが増す場合はファクトリー／@TestSetup を使用する	データ作成を 1 か所にまとめて一貫性を保ち、各テストメソッドの間でロールバックできます
非同期処理では Test.startTest() と Test.stopTest() を組み合わせる	アサーションの前に、非同期処理（キュー可能、future）が完了するようにします
不安定な組織依存をテスト内に隠さない	組織の状態に起因する断続的な失敗を防ぎます

---

注意事項

問題	解決策
ローカルではテストが成功するが、CI 組織では失敗する	SeeAllData=true や、組織固有のレコードに対する宣言されていない依存関係がないか確認します
リファクタリング後にカバレッジが予想外に低下する	まずクラス単位のテストを実行し、次に RunLocalTests まで範囲を広げて確認します
コールアウトテストで「Uncommitted work pending」エラーが発生する	Test.startTest() で囲まない限り、同じテストコンテキスト内で DML と HTTP コールアウトを混在させることはできません
テストでモックが適用されない	コールアウトを行うコードより前に Test.setMock() が呼び出されていることを確認します
テストメソッドで @TestSetup のデータが見つからない	@TestSetup のデータはテストメソッドごとにコミットされます。再クエリし、static 変数には保存しないでください
必要なアクセスレベルチェックがない API バージョン 67.0 以降	失敗した SOQL／DML のスタックトレースで CRUD／FLS アクセスエラーを確認します。ユーザーモードの動作を意図する場合は、割り当て済みの権限セットを使用して System.runAs を実行します。システムアクセスが必要な場合は、正当な理由のある SYSTEM_MODE の使用経路を文書化します

出力形式

完了したら、次の順序で報告してください。

1. 実行したテスト
2. 合格／不合格の概要
3. カバレッジの結果
4. 根本原因の調査結果
5. 修正または次回実行時の推奨事項

推奨形式：

Test run: <scope>
Org: <alias>
Result: <passed / partial / failed>
Coverage: <percent / key classes>
Issues: <highest-signal failures>
Next step: <fix class, add test, rerun scope, or widen regression>

---

スキル間の連携

必要な作業	委任先	理由
本番コードの修正またはテストクラスの作成	platform-apex-generate スキル	コードの生成と修正
大量データ／エッジケースのテストデータの作成	platform-data-manage	現実的なテストデータセット
更新したテストの組織へのデプロイ	platform-metadata-deploy	デプロイのワークフロー
詳細なランタイムログの調査	platform-apex-logs-debug	より詳細な失敗分析

---

参照ファイル一覧

ファイル	参照するタイミング
references/cli-commands.md	sf apex run test のすべてのコマンドフラグ、出力形式、非同期実行、カバレッジコマンド
references/test-patterns.md	テストクラスのテンプレート — 基本、大量（251件以上）、モックコールアウト、データファクトリーのパターン
references/testing-best-practices.md	テストの基本原則 — AAA パターン、命名規則、大量データ、ネガティブテスト、モックの戦略
references/test-fix-loop.md	エージェント型テスト修正ループの実装と、失敗分析の判断ツリー
references/mocking-patterns.md	HttpCalloutMock、DML モック、StubProvider、セレクターモックのパターン
references/performance-optimization.md	テスト実行時間を短縮する手法 — DML モック、SOQL モック、ループの最適化
assets/basic-test.cls	テンプレート：@TestSetup、正常系／異常系／大量データ／エッジケースの各メソッドを含む標準テストクラス
assets/bulk-test.cls	テンプレート：200件のトリガーバッチ境界を超える、251件以上のレコードを使った大量データテスト
assets/mock-callout-test.cls	テンプレート：HttpCalloutMock を使用した HTTP コールアウトのモック
assets/test-data-factory.cls	テンプレート：作成および挿入用ヘルパーを備えた再利用可能な TestDataFactory
assets/dml-mock.cls	テンプレート：データベースを使用しないユニットテスト用の IDML インターフェースと DMLMock の実装
assets/stub-provider-example.cls	テンプレート：StubProvider ベースの依存性注入スタブ
scripts/parse-test-results.py	ツール実行後のフック — sf apex run test の JSON 出力を解析し、自動修正ループ用に失敗を整形

---

スコアガイド

スコア	意味
108+	本番環境に適した高いテスト信頼性
96–107	軽微な不足はあるものの、良好なテストスイート
84–95	許容範囲ですが、カバレッジ／アサーションの強化が必要です
< 84	基準未満です。信頼して使用する前に見直してください