Codexにテストを依頼するとき：正常例・境界条件・失敗条件

Codexにテスト追加を頼んでも、正常入力一つだけを確認するコードができる場合があります。必要なのはテストファイル数より保証したい動作です。入力、期待結果、失敗時の処理を先に決めると、実装をそのままなぞったテストか判断しやすくなります。

この記事は架空の予約数量検証関数を例にします。製品の実利用上限やCodex使用量の数字ではありません。依頼書と事例表は自分のプロジェクト向けに変える例であり、この記事でそのテストを実行した意味ではありません。

数量検証の正常・境界・失敗例の一覧

1. テスト前に関数の約束を書く

例のvalidate_quantityは整数1～5を許可し、それ以外に検証エラーを返すと決めます。成功とエラーの形式は実プロジェクトの契約に従う必要があります。実装の結果をそのまま期待値にせず、望む動作を先に定義する段階です。

例は0、6、負数、小数、文字列、欠落入力を拒否します。数字に見える文字列の自動変換も別の決定です。「適切な数量なら成功」ではCodexが適切さを推定する必要があるため、許容範囲を文と表で固定してください。

OpenAIのCodexコード近代化例は正常フローと境界例を計画し各入力・出力を整理する過程を示します。公式プロンプト案内も対象関数を指定し正常・境界例を扱う依頼方法を説明します。以下はその原理を小機能へ自作適用した例です。

2. 正常例は使用目的を代表するよう選ぶ

架空関数へ3を入れて成功を期待するのは正常例です。同じ中間値を別名で何度も調べても重要条件は増えません。戻り値種類、正規化数量、呼出後の状態など利用者が依存する実結果を確認するよう決めます。

単純検証だけの関数なら保存領域の変更まで調べる理由はありません。一方、予約APIの契約が成功要求の一回保存なら、保存数量と応答を確認できます。関数単体テストとAPI経由テストの範囲を混ぜなければ原因を探しやすくなります。

区分	説明用の入力	契約による期待
正常な中間値	3	成功、数量3を維持
最小許容値	1	成功
最大許容値	5	成功
最小未満	0	検証エラー
最大超過	6	検証エラー
型が異なる	文字列3、小数3.5	変換せず検証エラー

表の結果は例の契約を決めたためです。別サービスが文字列を許可すれば表も変わります。未確定契約は質問・未定として残し、AIの選んだ結果を製品要求に自動採用しません。

3. 境界はすぐ内側と外側を併せて見る

最大5の検査は5の成功と6の失敗を見ます。4の成功だけでは5も拒否する実装ミスを逃します。最小も1の成功と0の失敗をつなげ両側を示します。境界の理由をテスト名や短い説明に残してください。

個数と日付では境界の単位が違います。個数は整数一段ですが予約時刻はタイムゾーン、端点包含、入力精度が必要です。「期限直前」を試すなら期限時刻を先に明記します。数量表を全時間条件へそのまま移しません。

小数拒否契約では1.5も別失敗条件です。範囲比較だけでは型契約違反が漏れるためです。言語が真偽値と整数をどう扱うか確認し、製品が真偽値を数量として受け取るか独立に決めてください。

4. 失敗条件はエラー内容と後の状態を決める

誤入力は「失敗すればよい」だけでなく必要エラー形式を決めます。例外、エラーオブジェクト、API応答でテストは変わります。既存のエラー処理慣例を読むようCodexへ依頼してください。

失敗入力を保存しない契約ならそれも確認します。架空の予約APIで検証エラー後に予約数が増えないと決められます。文言だけ見て保存状態を逃すと期待結果の一部しか調べていません。

エラーメッセージ全文の固定が必要かも判断してください。保証するエラーコードを検査し、文言が頻繁に変わる製品なら全文比較は保守負担になり得ます。契約に応じ検査の強さを選びます。

5. Codexへ渡す依頼書を作る

関数と関連ファイル、許可入力、期待結果、既存テスト位置、実行方法を入れます。パスは実リポジトリで確認したものに変えてください。新ツール設置を推定させるより、既存ツールとコマンドを先に読む範囲にできます。

validate_quantityと既存テストを読み、同じ慣例で追加してください。契約は整数1～5だけ成功し、文字列を自動変換しません。3、1、5の成功と0、6、負数、小数、文字列、欠落入力の失敗を区別してください。真偽値処理とエラー形式は既存契約を確認し、不明なら先に知らせてください。実装をテストへ合わせる前に契約との差を報告してください。関連テストを実行し、コマンド・結果・実行不能条件を書いてください。

全プロジェクトに合う依頼書ではありません。存在しない関数名やコマンドでは検証が始まらない場合があります。引数、呼出経路、依存性準備を確認し、不要な配備作業まで範囲に入れません。

6. 実装をなぞるだけのテストを見つける

期待値の由来を確認します。検査関数で期待値も計算すると同じ誤りを二度計算して通過し得ます。許容範囲は独立契約表から取り、出力の重要部分を直接確認する必要があります。

架空の誤実装が5を拒否すると考えます。最大許容値テストが失敗して初めて範囲契約を守る検査です。3だけならミスを逃し得ます。これは検出対象を点検する思考実験で実コード変更試験ではありません。

モックを使ったら代替対象も読みます。保存領域モックは外部サーバーの実保存を証明しません。正しい入力で保存要求した確認と、外部システムまで実動作した確認を分けてください。

7. 実行結果はファイル存在と区別する

報告された状態	確認する根拠	意味
テスト作成	追加コードと条件表	検査準備
テスト発見	実行器が選んだ一覧	対象の包含
実行成功	コマンド・終了結果・成功数	実行範囲の結果
スキップ	条件と省略項目	未検証範囲
実行不能	環境エラーと原因	検証が残る

正常終了でもテストが一つも選ばれなければ意図する検査結果ではありません。フィルター、実行場所、発見数を読んでください。依存性不足なら製品コード失敗と環境準備失敗を分けて報告します。

公式プロンプト案内は修正後に関連する小テストと検査コマンドを実行し報告する方式を説明します。成功だけより何のコマンドで何を確認したか残すと範囲を理解できます。未実行条件を完了数に加えません。

8. 失敗時は契約・テスト・実装を照合

入力、期待値、実値、契約表を照合します。期待値が誤りか実装が契約違反かもしれません。通過のため期待値だけ現結果へ直すと意図が消えるため変更根拠を説明する必要があります。

契約変更の製品決定なら理由と影響条件を先に記録して更新します。実装ミスなら修正後に同失敗例が解消し周辺条件が維持されるか確認します。既存成功検査に新失敗が出たら差も見ます。

最後は「正常使用を代表するか、境界両側を見るか、失敗結果と状態を見るか、実実行範囲が明確か」です。望む動作を契約に書き独立確認を依頼すると、テスト目的とCodex結果がつながります。

公式情報源と執筆基準

• OpenAI：プロンプト — テスト作成と検証フロー
• OpenAI：Codexによるコードベース近代化 — 検証とテスト計画

資料確認日：2026-10-07。実際に開いた公式資料に基づきAIが作成した説明です。別途表示した計算・コード・点検事例は説明用であり、利用者環境を直接試験したり実測したりした結果ではありません。公開日には機能と資料の変更状況を再確認します。