HowTo_Test-DrivenDevelopment.md
1. TDDの具体例（計算機アプリの「割り算」機能）
Pythonを例に、具体的にどう進めるかを解説します。
ステップ1：🔴 Red（失敗するテストを書く）
まだ中身が何もない状態で、「割り算のテスト」だけを先に書きます。
# test_main.py (テストファイル)
def test_divide():
assert divide(10, 2) == 5 # 10÷2は5になるはずだ！
この時点でテストを実行すると、divideという関数が存在しないため、 **当然エラー（赤色）**になります。
ステップ2：🟢 Green（最短でテストを通す）
テストを通すためだけに、必要最小限のコードを書きます。 「正しく書く」より「緑にする」のが優先です。
# main.py (本体ファイル)
def divide(a, b):
return 5 # とりあえずテストが期待している「5」を返すだけ
これでテストを実行すると、10÷2の期待値である5が返ってくるため、テスト成功（緑色）になります。
ステップ3：🔵 Refactor（リファクタ）
「とりあえず5を返す」という今のコードを、汎用的な正しい計算式に書き換えます。
# main.py (本体ファイル)
def divide(a, b):
return a / b # 正しい計算式に修正
修正後、もう一度テストを実行します。ここで 緑色のままなら、書き換えに成功したことになります。
さらなるサイクル：新たな🔴 Red
次に、「0で割った時にエラーが出るか？」という新しいテストを追加します。
def test_divide_by_zero():
# 0で割ったら例外が出るはずだ
with pytest.raises(ZeroDivisionError):
divide(10, 0)
これを実行すると、本体側で対策していないので **エラー（赤色）**になります。ここからまた🟢 Greenを目指して本体を修正する……という風に、少しずつプログラムを完成させていきます。
賢い使い方のポイント
このサイクルを繰り返すと、 **「一度作った機能が、後から追加した機能のせいで壊れていないか」**を、テストボタン一つでいつでも確認できるようになります。これがTDDの最大の強みです。
要件定義をした後、「失敗するテストを書く」時に、どのような観点で失敗するテストの範囲を決めるべきですか？例えば、データ型は必ず範囲に入れる、など決まった基準などありますか？
要件定義からテスト設計に落とし込む際、「どこまでテストを書くべきか」という基準は非常に重要です。2026年現在のソフトウェア開発では、 **「正常系」「異常系」「境界値」**という3つの観点で範囲を決めるのが一般的です。
以下の優先順位と基準でテストケースを作成してみてください。
1. 正常系：要件通りの「ハッピーパス」
まずは要件定義書に書かれている「一番メインの動き」をテストします。
- **観点:**入力に対して、期待通りの出力が返ってくるか。
- 具体例:「ユーザーが正しいIDとパスを入力したらログインできる」「カートに商品を入れたら合計金額が正しく計算される」など。
- **基準:**要件定義の「機能一覧」がすべて網羅されていること。
2. 境界値（ボーダーライン）：最もバグが出やすい場所
データ型そのものよりも、その **「境目」**をテストに含めるのがプロの鉄則です。
- **観点:**制限値の「ちょうど」「+1」「-1」を狙います。
- 具体例:
- 「100文字以内」という要件なら、99文字、100文字（成功）、101文字（失敗）をテスト。
- 「20歳以上」なら、19歳（失敗）、20歳（成功）をテスト。
- **基準:**不等号（< や <=）の書き間違いは非常に多いため、必ず範囲に入れます。
3. 異常系：意地悪な入力（データ型など）
プログラムが壊れないように、想定外のデータが来た時の挙動をテストします。
- **観点:**データ型が違う、中身が空、存在しないデータなど。
- 具体例:
- **データ型:**数値が必要な場所に文字列を入れる（"abc"など）。
- **Null/Empty:**何も入力しない、または None を渡す。
- **形式:**メールアドレスの形式ではない文字列を入れる。
- **基準:**2026年現在は、TypeScriptやPythonの型ヒントで「型」のミスは防げることが多いため、テストでは「型は合っているが意味的に不正なデータ（例：年齢に-100を入れる）」を重視します。
4. 2026年流：AIエージェントへの指示出し基準
VS CodeでAI（GitHub Copilotなど）に「失敗するテストを書いて」と頼む際は、以下の条件を基準として伝えると賢いテストが作れます。
AIへのプロンプト例:
「この要件に基づいたテストケースを作成して。観点は ①正常な計算結果、②数値が0やマイナスの時の境界値、③引数が未定義(null)の時のエラーハンドリング を含めて。」
基準のまとめ表
| テストの観点 |
決まった基準 |
理由 |
| 正常系 |
要件のメインシナリオ |
動くことの最低証明 |
| 境界値 |
上限・下限の前後数値 |
ロジックミスが最も多い場所 |
| データ型 |
型エラーや空文字 |
システム停止を防ぐ（堅牢性） |
| エラー処理 |
期待されるエラーが出るか |
ユーザーに不親切な強制終了を防ぐ |
アドバイス
最初は「すべての組み合わせ」をテストしようとすると、テストコードを書くだけで日が暮れてしまいます。まずは **「正常系1つ」と「怪しい境界値2つ」**程度から始め、バグが出そうなところを重点的に攻めるのが、学習を継続させるコツです。
HowTo_Test-DrivenDevelopment.md
1. TDDの具体例（計算機アプリの「割り算」機能）
Pythonを例に、具体的にどう進めるかを解説します。
ステップ1：🔴 Red（失敗するテストを書く）
まだ中身が何もない状態で、「割り算のテスト」だけを先に書きます。
この時点でテストを実行すると、divideという関数が存在しないため、 **当然エラー（赤色）**になります。
ステップ2：🟢 Green（最短でテストを通す）
テストを通すためだけに、必要最小限のコードを書きます。 「正しく書く」より「緑にする」のが優先です。
これでテストを実行すると、10÷2の期待値である5が返ってくるため、テスト成功（緑色）になります。
ステップ3：🔵 Refactor（リファクタ）
「とりあえず5を返す」という今のコードを、汎用的な正しい計算式に書き換えます。
修正後、もう一度テストを実行します。ここで 緑色のままなら、書き換えに成功したことになります。
さらなるサイクル：新たな🔴 Red
次に、「0で割った時にエラーが出るか？」という新しいテストを追加します。
これを実行すると、本体側で対策していないので **エラー（赤色）**になります。ここからまた🟢 Greenを目指して本体を修正する……という風に、少しずつプログラムを完成させていきます。
賢い使い方のポイント
このサイクルを繰り返すと、 **「一度作った機能が、後から追加した機能のせいで壊れていないか」**を、テストボタン一つでいつでも確認できるようになります。これがTDDの最大の強みです。
要件定義をした後、「失敗するテストを書く」時に、どのような観点で失敗するテストの範囲を決めるべきですか？例えば、データ型は必ず範囲に入れる、など決まった基準などありますか？
要件定義からテスト設計に落とし込む際、「どこまでテストを書くべきか」という基準は非常に重要です。2026年現在のソフトウェア開発では、 **「正常系」「異常系」「境界値」**という3つの観点で範囲を決めるのが一般的です。
以下の優先順位と基準でテストケースを作成してみてください。
1. 正常系：要件通りの「ハッピーパス」
まずは要件定義書に書かれている「一番メインの動き」をテストします。
2. 境界値（ボーダーライン）：最もバグが出やすい場所
データ型そのものよりも、その **「境目」**をテストに含めるのがプロの鉄則です。
3. 異常系：意地悪な入力（データ型など）
プログラムが壊れないように、想定外のデータが来た時の挙動をテストします。
4. 2026年流：AIエージェントへの指示出し基準
VS CodeでAI（GitHub Copilotなど）に「失敗するテストを書いて」と頼む際は、以下の条件を基準として伝えると賢いテストが作れます。
基準のまとめ表
アドバイス
最初は「すべての組み合わせ」をテストしようとすると、テストコードを書くだけで日が暮れてしまいます。まずは **「正常系1つ」と「怪しい境界値2つ」**程度から始め、バグが出そうなところを重点的に攻めるのが、学習を継続させるコツです。