関数に合わせたテストコードの作成

正常系・境界値・異常系に分けて質の高いテストを作成する

プロンプト · 変数 2個

以下の関数の単体テストを{{テスト ツール}}で作成してください。テストするケースを「正常系・境界値・異常系と例外」の3グループに分類し、各グループで実際に結果が分岐する重要なケースのみを厳選してください。

形式:まず、どのケースをなぜテストするのかを表形式で整理してください。列は「グループ・入力値・期待される結果・このケースを入れた理由」としてください。その後、表の順番通りにテストコードを記述してください。テスト名を見ただけで何を検証しているのかが分かるように命名してください。

コードに存在しない関数・設定・データは勝手に捏造せず、必要な場合はモック等で代用した上で、何を代用したかをコメントに残してください。テストケースは12個以内に収め、値を変えただけの同じ検証は1つのテストにまとめてください。

コードを書き終えた後、各テストが表に記載したケースを正しく検証できているかセルフチェックしてください。関数をどのように変更しても常にパスしてしまうような無意味なテストがあれば削除し、削除した理由を最後に1行で教えてください。

コード: """ {{コード}} """

コピーしたらここに貼り付け · ChatGPT・Claudeはプロンプト入りで開きます ChatGPTで開く ↗Claudeで開く ↗Geminiで開く ↗ ビルダーで編集 授業用カード画像を保存

このプロンプトには個人情報が入りうる変数があります。実名・番号・会社名は仮名に置き換えてください。

なぜこう書くのか

課題
以下の関数の単体テストを{{テスト ツール}}で作成してください。テストするケースを「正常系・境界値・異常系と例外」の3グループに分類し、各グループで実際に結果が分岐する重要なケースのみを厳選してください。
形式
形式:まず、どのケースをなぜテストするのかを表形式で整理してください。列は「グループ・入力値・期待される結果・このケースを入れた理由」としてください。その後、表の順番通りにテストコードを記述してください。テスト名を見ただけで何を検証しているのかが分かるように命名してください。
制約
コードに存在しない関数・設定・データは勝手に捏造せず、必要な場合はモック等で代用した上で、何を代用したかをコメントに残してください。テストケースは12個以内に収め、値を変えただけの同じ検証は1つのテストにまとめてください。
自己チェック
コードを書き終えた後、各テストが表に記載したケースを正しく検証できているかセルフチェックしてください。関数をどのように変更しても常にパスしてしまうような無意味なテストがあれば削除し、削除した理由を最後に1行で教えてください。
入力資料
コード: """ {{コード}} """

テストコード作成プロンプトで単に「テストを作って」と指示すると、正常に動くケースばかりが10個ほど出力されがちです。値が違うだけの正常系テストが次々とパスするため安心しがちですが、本当にバグが潜みやすい境界値や例外処理が一度も通らない状態になります。

課題の指示がその問題に直接アプローチします。ケースを「正常系・境界値・異常系と例外」の3つに分けるよう求めると、AIは各グループを埋めるために関数の条件分岐を再読します。上記の例であれば、3万円や5万円といった判定の境目や、0や負の数のような例外が発生するポイントが浮き彫りになります。

形式でコードより先に表を求めるのは、レビューの順番を整えるためです。テストコードを先に見ると構文だけを流し読みしてしまいますが、表を見れば漏れているケースにすぐ気づけます。「このケースを入れた理由」列を設けることで、AI自身が無意味なテストを省くようになります。

「テストは12個以内に収める」という制約も意図的です。上限を設けないと正常系の値違いだけで20個も出力され、リスト全体を確認しなくなります。上限を設けることで、AI自身が残すべきものを厳選し、結果として境界値テストが優先されます。

最後の段落では作成後のセルフチェックを行わせています。ChatGPTなどの単体テスト生成でよくある「何を直しても通ってしまう無意味なテスト」を、一度振り返らせることで大幅に削減できます。コードを"""で囲んでいるのは、関数内の文字列やコメントがAIへの指示として誤読されるのを防ぐためです。

用語が分からなければAha AIで: output-format, hallucination

悪い例との比較

よくある悪い例

この関数のテストコード書いて

(コード貼り付け)

正常な入力をいくつか入れて結果を確認するだけのテストが出力されます。条件が切り替わる境界値や例外が抜けており、コードにない設定ファイルやフィクスチャを前提としたコードが混ざってそのまま実行できないことも多々あります。パスを示す緑色のログだけを見て安心してしまうのが最も危険な点です。

バリエーション

既存のテストから不足分だけを探したいとき

既存のテストから不足分だけを探したいとき

以下に関数と既存のテストコードが含まれています。新しいテストをいきなり書くのではなく、まだ検証されていないケースのみを表で抽出してください。列は「未検証のケース・なぜ必要か・リスク度」としてください。その後、リスク度が高いものから順に{{テスト ツール}}のテストコードを3つだけ書いてください。

""" {{コード}} """

すでにテストが存在する場合に使います。不足分をまず表形式で受け取ることで、似たようなテストが増えるのを防げます。

テストがなぜ失敗するかわからないとき

テストがなぜ失敗するかわからないとき

以下の{{テスト ツール}}のテストが失敗します。コードとテストのどちらに問題があるかをまず判断し、その根拠を教えてください。テストをパスさせるためだけに期待値を安易に変更する提案はしないでください。

""" {{コード}} """

失敗したテストを貼り付けると、AIが期待値を勝手に書き換えて無理やりパスさせることがよくあります。その抜け道をあらかじめ塞いでおきます。

モデル別の注意

テストが通るかどうかは、必ず実際に実行して確認してください。実行していないテストコードは、名前はもっともらしくても実際には通らないことがあります。

テストツールのバージョンによってアサーション関数の名称が異なる場合があります。出力に違和感がある場合は「使用しているツールのバージョンは〇〇です」と補足して再度指示してください。

関連プロンプト

最終更新 2026-09-02 · 誤りがありますか? 知らせる