analyzing-test-failures

分析テスト失敗

タイプ： 純粋な推論 — システム呼び出しもコードの作成も行いません。

機能： テスト失敗またはCode Analyzerの違反ペイロードを解析して平易な説明を作成し、失敗したテストごとに優先順位を付けた具体的な改善案を提示します。各修正がテストと本番コードのどちらに属するかも示します。生のJSON、スタックトレース、APIエラー本文をユーザーに決して公開しません。

---

前提条件

失敗ペイロードを受け取るのではなく、自分で取得する必要がある場合は、最初にchecking-devops-prerequisitesを読み込み、次にpolling-test-resultsを使用して実行結果を取得します。ペイロードがすでにコンテキストにある場合、前提条件は不要です。これは純粋な推論です。

---

入力

• polling-test-resultsスキルから提供されたJSON形式の失敗ペイロード、またはテスト実行やCode Analyzerの実行結果からコンテキストに直接貼り付けられたペイロード。失敗したテストごとに、特に次の情報が必要です。
  • テストメソッド名
  • 失敗メッセージ（アサーションエラーまたは例外テキスト）
  • 失敗カテゴリ（アサーション失敗、未処理例外、タイムアウト、コンパイルエラー）

---

空の組織／データなしの場合

ペイロードに失敗や違反が含まれていない場合は、その旨を明確に報告します（例：「提供された実行結果に失敗は見つかりませんでした。」）。その後、処理を終了します。失敗、違反、改善案が存在しない場合に、それらを捏造してはいけません。

---

推論手順

1. 失敗カテゴリを特定します。

   カテゴリ	説明
   アサーション失敗	テストのアサーションに失敗しました（期待値と実際の値が一致しません）
   例外	未処理の例外がスローされました
   Code Analyzerの違反	静的解析ルールに違反しています（例：ApexCRUDViolation、ApexSharingViolations）
   タイムアウト	テストが実行時間の上限を超えました
   コンパイルエラー	クラスをコンパイルできませんでした

2. 失敗ごとに、次の情報を抽出して平易な言葉で説明します。

   • 該当するファイル名とクラス名
   • メソッド名
   • 行番号
   • 違反したルールまたはアサーションの内容（平易な言葉で）
   • 修正の方向性（コードは記述しない）

3. 複数の失敗がある場合は、カテゴリ別にまとめます。

---

出力形式

Test failure summary:

<N> failure(s) found:

1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
   What happened: <plain-language description>
   Rule violated: <ruleName or assertion description>
   Fix direction: <plain-language suggestion>

2. [<Category>] `<ClassName2>.cls` — `<methodName2>()` at line <N>
   ...

---

Code Analyzerの違反

違反については、必ず次の情報を含めます。

• ルール名を平易な言葉に置き換えたもの（例：「ApexCRUDViolation」→「SOQLクエリの前にオブジェクトレベルの権限を確認せずにクエリが実行されました」）
• 正確な行番号
• 修正の方向性（例：「クエリの前にSchema.sObjectType.Account.isAccessible()の確認を追加します」）

---

平易な言葉を使うルール

生のスタックトレース、JSONペイロード、内部のSalesforceエラーコードを出力に貼り付けてはいけません。必ずファイル名、メソッド、行番号、平易な説明に置き換えてください。

---

改善案の提示

このセクションは、テストの実行が完了し、失敗があった後に呼び出してください。静的なソースコードに対して呼び出してはいけません。失敗メッセージは主要な手掛かりです。テストが期待した結果と実際に起きたことを説明しており、テストでどのような処理を改善する必要があるかが直接分かります。

1 — 各失敗メッセージを読む

実行結果に含まれる失敗したテストごとに、次の情報を抽出します。

• テストメソッド名
• 失敗メッセージ（アサーションエラーまたは例外メッセージ）
• 失敗カテゴリ（アサーション失敗、未処理例外、タイムアウト、コンパイルエラー）

2 — テストで扱われていない内容を推測する

失敗メッセージをもとに、根本原因のパターンを特定します。

失敗パターン	改善の提案
NullPointerException	テストで null 入力が処理されていません。null チェックを追加するか、データが確実に存在するようにテストのセットアップを行ってください
Assertion failed: expected X but was Y	アサーションの期待値が誤っているか、テストデータのセットアップで適切な状態が作られていません
List has no rows for assignment	テストで存在しないデータをクエリしています。テストのセットアップが不完全です
System.LimitException: Too many SOQL queries	テストがガバナ制限に達しています。テスト対象のコードまたはテストのセットアップでクエリが多すぎます
Insufficient access rights on cross-reference id	テストユーザーに必要な権限がありません。適切なプロファイルまたは権限セットを持つユーザーとしてテストを実行する必要があります
DML currently not allowed	DML が許可されていないコンテキストから呼び出されたメソッド内で、テストが DML を実行しています
Code Analyzer の違反メッセージ	本番コードが特定のルールに違反しています。テストで問題が明らかになりましたが、修正すべきなのはテストではなく本番コードです

3 — 実行可能な提案を作成する

それぞれの失敗について、わかりやすい言葉で以下を説明します。

• その失敗から、テストで何が扱われていないとわかるか
• テストの堅牢性を高めるため、具体的に何を追加または変更する必要があるか
• 修正箇所がテスト（アサーション、セットアップ、権限）か、本番コード（テストは正しいが、テスト対象のコードに問題がある）か

テストを書き換えないでください。変更が必要な内容とその理由だけを説明してください。

改善の出力形式

Test improvement suggestions based on execution results:

`<testMethodName>()` — [Assertion Failure / Exception / etc.]
Failure: "<failure message>"
What this reveals: <plain-language explanation>
Suggestion: <specific, actionable recommendation>
Fix location: Test | Production code

`<testMethodName2>()` — [NullPointerException]
Failure: "Attempt to de-reference a null object"
What this reveals: The test is calling the method without setting up the required input data
Suggestion: Add test data setup for <object/field> before calling the method
Fix location: Test

Overall: <N> improvement(s) across <M> failed test(s).

テストの修正と本番コードの修正

修正箇所：本番コードとして示された提案は、テストによって明らかになったコードの欠陥を示します。テストロジック自体に問題はありません。テストの品質を理由にスイートの昇格を妨げるべきではありません。これらは本番コードの欠陥として別途追跡してください。

修正箇所：テストとして示された提案は、テストを強化する必要があることを示します。セットアップの不足、誤ったアサーション、エッジケース（null 入力、一括処理するレコード数、権限コンテキストの混在、ガバナ制限の境界）のカバレッジ不足などが該当します。

---

関連スキル

• polling-test-results — このスキルに渡す失敗ペイロードを取得します。
• creating-fix-work-item — 分析結果から追跡対象の修正項目を作成するとき、またはユーザーが対応を決めた後に、承認済みの改善提案を作業項目として追跡するときに使用します。