単体テスト

観点を「保存できる形」にする

前回のP-03で、正常系・異常系・境界値という3つの観点を手に入れました。ただ、観点を頭で唱えるだけでは、変更のたびに一から手で確かめ直すことになります。この講義では、その観点をコードとして保存し、自動で何度でも確認できる形に変えます。単体テストは、O-10で名前だけ触れた自動検査の、いちばん小さな単位でもあります。ここから、確認を「その場限りの作業」から「積み上がる資産」へと変えていきます。

このスライドのポイント

• P-03で正常系・異常系・境界値という観点を手に入れた
• しかし観点を頭の中で唱えるだけでは、変更のたびに毎回手で確かめる必要がある
• 単体テストは、その観点をコードとして保存し、何度でも自動で確認できる形にする第一歩
• O-10で名前だけ触れた自動検査の、最小単位にあたる

単体テストとは

単体テストとは、E-07やI-02で扱った関数や部品を1つだけ切り離して、ある入力を与えたときに期待する出力が返るかを、コードで自動的に確認するテストです。コードで書くので、何度でも一瞬で実行できます。人が手で確かめる場合と違い、疲れて見落とすことがなく、毎回まったく同じ基準で判定してくれます。ちなみに、単体テストの書きやすさは、N-05やN-06で学んだ設計の良さのバロメーターでもあります。1つだけ切り離しにくい関数は、いろいろな役割が絡み合っている、というサインだからです。

このスライドのポイント

• 単体テスト＝関数や部品（E-07／I-02）を1つだけ切り離し、入力→期待する出力を自動で確認するテスト
• コードで書くので、何度でも一瞬で実行できる
• 手作業と違い、疲れず・見落とさず・毎回同じ基準で確認できる
• 書きやすさは設計の良さ（N-05／N-06）のバロメーターでもある

単体テストが無いと何が起きるか

単体テストが無いと、確認はすべて手作業になります。関数を1つ直すたびに、関係しそうな場所を全部、自分の手で確かめ直すことになります。バイブコーディングでは、AIが生成した関数を、目で見て「動いていそうだ」と判断して受け入れることになりがちです。しかし目視の確認は、P-03で学んだ境界値や異常系を、どうしても見落とします。単体テストは、この目視だけの検収を、抜けのない自動判定に置き換えるための道具です。

このスライドのポイント

• 手動確認だけに頼ると、変更のたびに全部を手で確かめる羽目になる
• バイブコーディングでは、AIが生成した関数の検収も目視だけになる
• 目視は、境界値や異常系（P-03）を見落としやすい
• 「動いたように見える」で受け入れてしまう

テストの3部構成

単体テストは、どれも同じ3つの部分でできています。まず準備として、確認したい入力を用意します。次に実行として、対象の関数を呼びます。最後に検証として、返ってきた結果を、あらかじめ決めた期待する値と比べます。この3部構成を覚えておくと、どんなテストコードも同じ型で読めます。そして大切なのは、P-03で作った観点表の1行が、そのまま1つのテストに対応するということです。観点を先に出しておけば、テストは機械的に書き起こせます。

このスライドのポイント

• テストは3つの部分でできている: 準備→実行→検証
• 準備: 確認したい入力を用意する
• 実行: 対象の関数を呼ぶ
• 検証: 返ってきた結果を、期待する値と比べる
• P-03の観点表の1行が、1つのテストに対応する

例: 承認判定の関数にテストを付ける

具体例を見ます。J-07で扱った、1万円以上なら上長承認が必要かどうかを返すneedsApprovalという関数を対象にします。P-03で境界値として出した3つの点、9,999円、10,000円ちょうど、10,001円を、そのままテストにします。この3本を書いておくと、あとで承認ルールの変更をAIに頼んだときに、もし境界が1円ずれてしまっても、その瞬間にテストが失敗して知らせてくれます。これが「テストはAIの出力の検収装置」という考え方の、いちばん分かりやすい場面です。

このスライドのポイント

• 対象: J-07のneedsApproval関数（1万円以上なら上長承認が必要）
• P-03で出した境界3点をテストにする: 9,999円／10,000円ちょうど／10,001円
• 一度書けば、承認ルールをAIに変更させても境界のずれを即検知
• これが「テストはAIの出力の検収装置」の実感ポイント

技術サンプルカード: 境界値の単体テスト

これが実際のテストコードの姿です。1つのまとまりが、1つのケースに対応しています。needsApprovalに9,999円を渡したら承認不要、10,000円ちょうどと10,001円なら承認必要、という3つの一問一答が並んでいるだけです。1ケースは、入力と期待する結果の1組でできています。これは、M-09で決めた受入条件が、そのままコードになった姿だと考えてください。なお、具体的な書き方はテストの枠組みによって変わるので、形そのものを暗記する必要はありません。読み取れれば十分です。

混同しやすい概念

混同しやすいのが、単体テストと、画面を触っての動作確認の違いです。動作確認は、部品が全部つながった全体を動かして「なんとなく変だ」と気づく形になります。一方、単体テストは関数を1つだけ切り離して確かめます。切り離しているからこそ、テストが失敗したときに、原因はその関数の中だと即座に分かります。全体を動かして原因を探し回るのと比べて、場所の特定が段違いに速いのです。両方とも必要ですが、役割はこのようにはっきり分かれています。

このスライドのポイント

• 単体テスト vs 動作確認、を区別する

バイブコーディングでの確認点

バイブコーディングでは、AIに機能を作らせるときに「テストも一緒に書いてください」と添えるのを、いつもの型にしてください。生成物とセットでテストが付いてくれば、その場で自動の検収ができます。さらに強い進め方として、先に受入条件をテストとして書かせ、そのテストが通るように実装させる、というやり方もあります。作る前に合格ラインが固定されます。頼むときは「この関数の単体テストを、P-03の3分類で網羅して書いてください」と、観点まで指定するのがおすすめです。

このスライドのポイント

• AIに機能を作らせるとき「テストも一緒に書いて」を定型にする
• さらに強い型: 先に受入条件（M-09）をテストとして書かせ、そのあと実装させる
• 質問例:「この関数の単体テストを、P-03の3分類で網羅して書いてください」

まとめと次回

一問一答です。単体テストが失敗したとき、原因の場所はどこでしょうか。……答えは、その関数の中です。1つだけ切り離しているので、場所がすぐ特定できます。30秒でまとめます。単体テストとは、関数を切り離して行う自動の一問一答であり、P-03の観点表の1行が1本のテストになります。これがAIの出力を検収する装置になる、というのがこの講義の要点でした。次回は、部品を1つずつではなく、つなぎ目を確かめる結合テストへ進みます。関連資料は「テスト観点プロンプト50」と「リファクタリング指示文50」です。

このスライドのポイント

• 一問一答:「単体テストが失敗したとき、原因の場所は？」
• 30秒まとめ: 単体テスト＝関数を切り離した自動の一問一答。観点表の1行が1テスト。AIの検収装置になる
• 次回: つなぎ目を確かめる結合テストへ
• 関連資料: 「テスト観点プロンプト50」「リファクタリング指示文50」