Codex テスト 結果を確認するときは、画面に出たエラーをすべて一度に直そうとせず、「テスト全体の結果」→「最初に失敗したテスト」→「エラーが起きたファイルと行」の順に見ます。最初のエラーを再現し、原因を1つ修正してから同じテストを再実行すると、変更の影響を判断しやすくなります。
この記事では、テスト結果に表示される言葉の意味、失敗箇所の探し方、Codexへの伝え方、修正後に確認する項目を、開発初心者向けに説明します。
❓ 初心者の疑問
テストが赤くなったら、表示されたエラーを上から全部直せばよいですか？ 多くの場合は、最初に失敗したテストを調べます。後ろに並んだエラーは、最初の失敗が原因で連鎖していることがあるためです。
まずテスト結果を3種類に分ける
最初に、実行結果を「成功」「失敗」「実行できなかった状態」に分けます。表示の言葉はテストツールによって異なりますが、判断の考え方は共通です。
| 結果 | 何が分かるか | 次にすること |
|---|---|---|
| 成功・Passed | 実行した範囲のテスト条件を満たした | 変更内容と対象範囲を確認する |
| 失敗・Failed | 期待した結果と実際の結果が違う | 最初の失敗箇所と原因を調べる |
| エラー・Error | テストの準備や実行そのものが止まった | 依存関係、設定、入力、環境を確認する |
| スキップ・Skipped | 条件により実行されなかった | 意図したスキップか確認する |
📘 用語メモ
テストは、コードを変更したあとに「期待した動作になっているか」を自動で確認する仕組みです。例えば、合計金額を計算する関数に「100円と200円なら300円になる」という条件を与えます。
成功していても、プロジェクト全体を検査したとは限りません。一部のテストだけを実行している場合や、スキップされたテストがある場合は、確認範囲を記録しておきます。
最初に確認する4つの情報
1. どのコマンドを実行したか
まず、Codexが実行したコマンドを確認します。flutter test、pytest、npm testのように、プロジェクトごとにコマンドは違います。
同じ「テスト成功」でも、単体テストだけなのか、画面のテストや静的解析まで含むのかで意味が変わります。コマンドが分からないときは、Codexに「このコマンドが対象にしているテスト範囲を説明してください」と聞きましょう。
2. 成功・失敗した件数
次に、実行数、成功数、失敗数、スキップ数を見ます。失敗が1件なら原因を追いやすい一方、複数件なら同じ原因で連鎖している可能性があります。
件数だけで安心せず、失敗したテスト名とテストファイル名まで確認します。
3. 最初のエラーメッセージ
出力が長い場合は、一番下の赤い文字から読み始めるのではなく、最初に失敗したテストの見出しを探します。その近くに、期待値、実際の値、ファイル名、行番号が出ていることがあります。
例えば次のような表示なら、user_service_test.dartの42行目付近を確認します。
Expected: 3
Actual: 2
user_service_test.dart:42:74. 期待値と実際の値
Expectedはテストが期待した値、Actualは実際に返ってきた値です。2つを比べると、計算結果の違い、並び順の違い、空の値、型の違いなどに気づきやすくなります。
💡 ポイント
エラーの文章を読んでも原因が分からないときは、「何を期待し、何が返ったか」を日本語で1文に言い換えてください。原因を考える範囲が狭くなります。
Codexで失敗原因を調べる手順
STEP1：失敗したテストを1件に絞る
最初からプロジェクト全体を再実行するのではなく、失敗したテストファイルやテスト名を指定します。実行方法は言語やフレームワークによって異なるため、Codexには次のように依頼できます。
テスト結果を確認してください。
最初に失敗したテスト、期待値と実際の値、原因候補を分けて説明してください。
まだコードは変更せず、関連するファイルと、失敗したテストだけを再実行するコマンドを提案してください。STEP2：テストと実装を照らし合わせる
テスト側が期待している動作と、実装側が実際に行っている処理を比べます。ここで「テストの期待が古い」「実装が間違っている」「入力データの準備が違う」の3方向を確認します。
テストが失敗したからといって、必ず実装が悪いとは限りません。仕様変更後にテストの期待値を更新していないケースもあります。
STEP3：原因を1つだけ修正する
複数のファイルを同時に変更すると、どの変更で直ったのか分からなくなります。まずは原因として最も確度が高い1か所だけを修正し、差分を確認します。
✅ チェックリスト
実行コマンド、失敗したテスト名、期待値、実際の値、ファイル名と行番号、変更したファイル、再実行した結果を記録しましたか？
STEP4：同じテストを再実行する
修正後は、まず失敗していたテストを同じ条件で実行します。成功したら、次に関連するテスト、最後にプロジェクト全体のテストへ範囲を広げます。
Codexには「修正後に同じテストを再実行し、変更前後の結果を比較してください」と依頼すると、検証の目的が伝わります。テストを実行していないのに「直りました」と判断しないことが大切です。
よくある失敗パターンと改善方法
✖ 失敗例
エラーが大量に出たため、表示されたファイルを上から順にすべて書き換える。 改善例: 最初の失敗を特定し、期待値・実際の値・スタックトレースを確認してから、関連する最小範囲だけを変更する。
依存関係や設定が原因の場合
テストのコードではなく、パッケージの不足、環境変数、設定ファイル、データベース接続などが原因で実行できないことがあります。この場合は、失敗したテストの期待値を変える前に、エラーメッセージの「見つからないもの」や「接続できないもの」を確認します。
テストが不安定な場合
実行するたびに成功したり失敗したりするなら、時刻、乱数、ネットワーク、共有データ、実行順序が関係している可能性があります。何回中何回失敗したかを確認し、同じ条件を固定できるか調べます。
変更と無関係なテストが失敗した場合
変更したファイルと失敗したテストの関係を確認します。関係が薄い場合は、既存の失敗なのか、依存関係や環境の問題なのかを切り分け、無理に修正範囲を広げないようにします。
Codexにテスト結果を伝える依頼文
テスト結果だけを貼り付けるより、目的と制約を添えると調査しやすくなります。
テストが1件失敗しました。
目的：ログイン後のユーザー名表示を正しくする
実行コマンド：<実際に使ったコマンド>
失敗したテスト：<テスト名>
期待値：<期待した内容>
実際の値：<表示された内容>
依頼：原因候補を優先順位付きで説明し、最小の修正案を示してください。
修正前に、変更するファイルとテスト方法を確認してください。Codexの作業では、変更、テスト、結果確認を繰り返します。OpenAI公式の案内でも、変更後はテスト結果を確認し、必要なら同じ作業を続ける流れが示されています。結果の要約だけでなく、実際に実行されたコマンドと出力を根拠に判断しましょう。
❓ 初心者の疑問
テストが全部成功したら、そのまま公開してよいですか？ テストが確認した範囲では問題が見つからなかった、という意味です。差分、手動で確認すべき画面、未実行・スキップのテストも確認してから次へ進みます。
次に読むと理解が深まる記事
テストの失敗原因を調べるときは、プロジェクトの入口、実行コマンド、設定ファイルの場所が分かっていると判断が速くなります。
まとめ：テスト結果は「最初の失敗」を根拠に読む
Codexのテスト結果を読み解くときは、次の順で進めます。
- 実行したコマンドとテスト範囲を確認する
- 成功、失敗、エラー、スキップを分類する
- 最初に失敗したテストの期待値と実際の値を見る
- 関連するテストと実装を照らし合わせる
- 変更を1つに絞り、同じテストを再実行する
- 最後に関連テストと全体テストを確認する
👉 次にやること
次回テストが失敗したら、まず「失敗したテスト名・期待値・実際の値・行番号」の4項目だけをメモしてから、Codexへ原因調査を依頼してください。
