TDD（テスト駆動）50章：詳細アウトライン🧪✨（C# / Windows / AI前提）

前提環境（2026想定）🪟🔧

• .NET 10（LTS）＋ C# 14 を前提に進めます✨（.NET 10は2025/11リリース、2026/01/13時点で10.0.2が最新） (Microsoft)
• IDEは Visual Studio 2026 を基本にして、必要に応じて VS Code（C# Dev Kit） も補足します😊 (窓の杜)
• テストは xUnit（最新安定版・v3系） を基本にします🧪 (xUnit.net)
• AI（Copilot / Codex等）は**“常に使ってOK”**だけど、最終判断はテストと自分の意図でいきます🤖✅

---

Part 1：TDDの地図を持つ（迷子防止）🗺️😊（1〜6）

第1章：TDDって結局なに？（全体像を1枚にする）🙂

• ねらい：TDDを「作業手順」として説明できる
• 学ぶこと：テスト＝仕様、設計＝テストから育つ
• 手を動かす：超ミニ例で「テスト→実装→整理」を眺める
• AI：AIに「TDDの3ステップを短く説明して」と頼む→自分の言葉に直す
• チェック：TDDは“テストが先”であって“テストが多い”とは別

第2章：Red / Green / Refactor の意味を体で覚える🚦

• ねらい：3ステップを“最小単位”で回せる
• 学ぶこと：失敗の作り方／成功の最小化／整理の目的
• 手を動かす：失敗するテストをわざと書く→最短で通す
• AI：失敗ログを貼って「原因候補を3つ」と出させる
• チェック：Greenで“作り込み”しない（それは次）

第3章：「小さく刻む」練習（1ステップ10分以内）⏱️

• ねらい：課題を“細切れ”にできる
• 学ぶこと：受け入れ条件→最小テストへの分解
• 手を動かす：仕様文を3つの小テストに分割
• AI：仕様を貼って「最小テストの順番を提案して」
• チェック：粒度が大きいとRefactorが怖くなる

第4章：TDDが得意な領域／苦手な領域🎯

• ねらい：TDDを使う場所を選べる
• 学ぶこと：純粋ロジック◎／UI見た目△／外部I/Oは工夫
• 手を動かす：自分の過去コードを“テストしやすさ”で分類してみる
• AI：コード断片を貼って「テストしやすくする分離案」
• チェック：「全部TDD」じゃなく“効く所から”

第5章：テストは“仕様書”になる（読み物化のコツ）📘

• ねらい：あとで読めるテストを書ける
• 学ぶこと：意図が伝わる命名／Arrangeの見やすさ
• 手を動かす：テスト名を「日本語で意図→英語名へ」変換
• AI：命名候補を複数出させて、最も誤解が少ないものを選ぶ
• チェック：テストが“実装の写し”になると死ぬ😵

第6章：AI時代のTDD作法（使いどころを固定）🤖✅

• ねらい：AIで速度UPしつつ品質を落とさない
• 学ぶこと：AIは「案出し」「抜け探し」「置き換え提案」に強い
• 手を動かす：AIに“テストケース洗い出し”だけやらせる
• AI：固定プロンプト例（後述の章でも毎回使う）
• チェック：AIのコード採用条件＝「テストが通る＋意図に一致」

---

Part 2：環境づくり（手が止まらない状態にする）🪟🔧（7〜10）

第7章：Visual Studioでテストが回る土台を作る🏗️

• ねらい：新規プロジェクト＋テストが1分で起動
• 学ぶこと：ソリューション構成（App / Tests）
• 手を動かす：xUnitテストを1本作って実行
• AI：README雛形（実行手順）をAIに作らせる
• チェック：最初からフォルダが散らかると後がつらい

第8章：VSのテスト実行に慣れる（赤の読み方）🔍

• ねらい：失敗ログから原因を絞れる
• 学ぶこと：Assert失敗／例外／タイムアウトの違い
• 手を動かす：3種類の失敗をわざと起こして見分ける
• AI：ログを貼って「原因候補→確認手順」を出させる
• チェック：最初のうちは“焦らずログの型を見る”

第9章：dotnet test（CLI）も使えるようにする⌨️

• ねらい：IDE無しでもテストが回る
• 学ぶこと：dotnet test / フィルタ / 失敗時の出力
• 手を動かす：1テストだけ実行→失敗を確認
• AI：コマンド例をAIに整理させて自分用メモ化
• チェック：CIで必要になるのはだいたいCLI

第10章：VS Code補足（ミニ構成で迷わない）🧩

• ねらい：VS Codeでも“学習が続く”
• 学ぶこと：C# Dev Kit / テスト探索 / 実行
• 手を動かす：VS Codeでテストを1本追加→実行
• AI：VS Codeでの“ハマりがち”をAIに列挙させる
• チェック：メインはVS、VS Codeは補助でOK

---

Part 3：テストの書き方（読みやすさ最優先）🧪📚（11〜18）

第11章：AAA（Arrange/Act/Assert）で形を固定🧱

• ねらい：テストが毎回同じ形で書ける
• 学ぶこと：準備→実行→確認を混ぜない
• 手を動かす：散らかったテストをAAAに整形
• AI：テストを貼って「AAAに直して」
• チェック：Assertは最後に集める（読みやすさUP）

第12章：Assertの基本（何を確認すべき？）✅

• ねらい：テストが“ちゃんと検証”できる
• 学ぶこと：値／例外／コレクション／状態変化
• 手を動かす：同じ仕様を“3種類のAssert”で表現してみる
• AI：「この仕様でAssertするべき観点」を3つ出させる
• チェック：確認が弱いとテストが“通るだけ”になる😇

第13章：テスト名の付け方（読むだけで仕様）📝✨

• ねらい：失敗しても何が壊れたか即わかる
• 学ぶこと：Given/When/Then（または日本語でもOK）
• 手を動かす：命名が弱いテスト名を10個改善
• AI：命名案を3つ出させて「誤解が少ない」ものを選ぶ
• チェック：メソッド名の暗記じゃなく“振る舞い”を書く

第14章：1テスト1意図（欲張り禁止）🍰🙅‍♀️

• ねらい：壊れた理由が一瞬で分かる
• 学ぶこと：複数Assertの扱い（同一意図ならOK）
• 手を動かす：1テストに混ざった意図を分割
• AI：混ざってる意図をAIに見つけさせる
• チェック：失敗原因が多いテストは“読むのが地獄”

第15章：パラメータ化（同じ形でケースを増やす）🔁

• ねらい：境界値や例外ケースが増やしやすい
• 学ぶこと：Theory/Data（データ列挙の考え方）
• 手を動かす：境界値を5ケース追加
• AI：仕様から「境界値候補」を自動で列挙させる
• チェック：増やすほど読みづらいなら“分ける”

第16章：テストデータの作り方（小さく・分かりやすく）🧸

• ねらい：Arrangeがスッキリする
• 学ぶこと：テストデータビルダーの超入門
• 手を動かす：同じArrangeをヘルパー化
• AI：ビルダー雛形をAIに作らせて最小に削る
• チェック：共通化しすぎると意図が隠れる🙈

第17章：“決定性”の確保（テストが毎回同じ結果）🎲🚫

• ねらい：たまに落ちるテストを作らない
• 学ぶこと：時間／乱数／並列／順序依存の罠
• 手を動かす：乱数を固定して安定化
• AI：不安定になりそうな点をAIに指摘させる
• チェック：フレーク（たまに落ちる）は敵😵‍💫

第18章：ここまでの総合ミニ演習：カフェ会計①☕️🧾

• ねらい：AAA＋命名＋境界値が一通りできる
• 学ぶこと：合計／税／端数（まずは簡単な仕様）
• 手を動かす：3テスト→最小実装→整理
• AI：テストケース案だけ出させる（実装は自分主導）
• チェック：Greenで作り込みしない（次章以降で育てる）

---

Part 4：TDDの“手筋”を覚える（設計が自然に整う）🧠✨（19〜28）

第19章：仮実装（ベタでもいいから先に通す）🩹

• ねらい：Red→Greenに最短で到達
• 学ぶこと：仮実装の役割（設計を後回しにする技）
• 手を動かす：一旦ベタで通してから次へ
• AI：仮実装を“やりすぎない”チェックをAIにさせる
• チェック：仮実装は“永住”させない😂

第20章：三角測量（2ケース目で一般化）📐

• ねらい：一般化のタイミングが分かる
• 学ぶこと：2例目でルールが見える
• 手を動かす：2ケース目のテスト追加→一般化
• AI：次に追加すべきテストケース候補を提案させる
• チェック：一般化が早すぎると複雑になる

第21章：明白な実装（迷いがない時は素直に）🌼

• ねらい：ムダに回り道しない
• 学ぶこと：仮実装／三角測量／明白の使い分け
• 手を動かす：同じ仕様を別の手で実装して比較
• AI：手の選択理由をAIに言語化させる（理解チェック）
• チェック：「いつも同じ手」になってない？

第22章：失敗の種類を増やす（例外のテスト入門）🚫🧪

• ねらい：異常系も“仕様”として書ける
• 学ぶこと：例外型／メッセージ／エラー分類（超基礎）
• 手を動かす：無効入力で例外を投げるテスト
• AI：想定すべき無効入力を列挙させる
• チェック：例外は“投げっぱなし”にしない（意味を持たせる）

第23章：“におい”を嗅ぐ（テストが設計の警報器）👃🚨

• ねらい：設計の崩れを早めに気付ける
• 学ぶこと：Arrangeが重い／依存が多い／テストが辛い＝設計改善サイン
• 手を動かす：辛いテストを1つ選び、原因を言語化
• AI：原因→改善案を3案出させる
• チェック：テストが辛いのに“気合で書く”のはNG

第24章：リファクタの安全運転（テストがある時の整理）🛡️

• ねらい：怖くなくコードを整えられる
• 学ぶこと：小さな置き換え／名前改善／重複除去
• 手を動かす：リネーム→抽出→整理（各手順でテスト実行）
• AI：リファクタ案をAIに出させて“最小”だけ採用
• チェック：一気に変えない、こまめにテスト

第25章：テスト側のリファクタ（テストもコード）🧹

• ねらい：テストが増えても読める
• 学ぶこと：共通化の限度／ヘルパーの作法
• 手を動かす：重複Arrangeを整理して読みやすく
• AI：共通化候補を出させて“やりすぎ”を削る
• チェック：ヘルパーが多すぎると意図が消える

第26章：カフェ会計②：割引・クーポン・上限🎟️🧾

• ねらい：仕様追加でも壊れない進め方
• 学ぶこと：小テスト追加→最小実装→整理を守る
• 手を動かす：割引ルールを段階的に足す
• AI：境界値（上限/下限/0円）案を出させる
• チェック：条件分岐が増えたら“設計サイン”かも

第27章：条件分岐地獄の回避（表にして考える）🗂️

• ねらい：ifが増える前に整理できる
• 学ぶこと：決定表／ルールの見える化
• 手を動かす：ルールを表にしてテストケース化
• AI：決定表のたたき台を作らせる
• チェック：仕様が増えたら“テストケース表”を更新

第28章：小さな設計の基本（超入門：責務を分ける）🧩

• ねらい：1クラスに全部入れない感覚をつくる
• 学ぶこと：責務／分離／名前の付け方
• 手を動かす：計算とルールを小さなクラスに分ける
• AI：クラス分割案を出させて“最小”だけ採用
• チェック：分けすぎもNG（必要になってからでOK）

---

Part 5：依存を切る（テストしやすい設計の入口）🔌✨（29〜40）

第29章：依存ってなに？（時間・乱数・外部）⏰🎲

• ねらい：テストを壊す“外部要因”を説明できる
• 学ぶこと：I/O境界の考え方（超基礎）
• 手を動かす：依存リストを作る（自分の題材で）
• AI：依存を列挙させて抜けを補う
• チェック：不安定の原因はだいたい依存

第30章：依存の差し替え①：インターフェースの最小導入🔁

• ねらい：差し替え可能にできる
• 学ぶこと：interfaceは“外側の都合”を閉じ込める
• 手を動かす：Clockをinterface化
• AI：interface名の候補を出させる（読みやすいのを採用）
• チェック：抽象化は“必要になった分だけ”

第31章：依存の差し替え②：コンストラクタ注入（DI入門）📦

• ねらい：newを減らしてテスト可能にする
• 学ぶこと：注入＝外から渡すだけ
• 手を動かす：newを消して注入に変える
• AI：差分が最小になる修正案を出させる
• チェック：DIコンテナはまだ不要（ここでは使わない）

第32章：スタブとモックの気持ち（混乱しない説明）🎭

• ねらい：テストダブルを使い分けられる
• 学ぶこと：スタブ＝返すだけ／モック＝呼ばれ方も確認
• 手を動かす：同じ依存をスタブでテスト→モックでテスト
• AI：違いを“自分の題材”で説明させて理解チェック
• チェック：最初はスタブ中心でOK

第33章：モックフレームワーク入門（最小だけ）🧪

• ねらい：必要な時だけ使える
• 学ぶこと：戻り値設定／呼び出し回数確認
• 手を動かす：外部通知（例：メール送信）をモック化
• AI：モック設定の雛形を出させて最小に削る
• チェック：モックしすぎると“実装の写し”になる

第34章：呼び出し確認（副作用を仕様にする）📣✅

• ねらい：「通知した/しない」をテストできる
• 学ぶこと：いつ呼ぶ？呼ばない？が仕様
• 手を動かす：条件で通知有無が変わるテスト
• AI：副作用の観点（通知・ログ・保存）を列挙させる
• チェック：副作用は“境界”に寄せると楽

第35章：例外の扱い（依存先が落ちた時）💥

• ねらい：外部失敗時の仕様を決められる
• 学ぶこと：リトライする？しない？ユーザーに何を返す？
• 手を動かす：依存が例外を投げるケースのテスト
• AI：失敗時の方針案を3つ出させる（採用は自分）
• チェック：例外を握りつぶすのはNG🙅‍♀️

第36章：テストを速く保つ（遅いテストは続かない）🐢➡️⚡️

• ねらい：テストの速度目標を持てる
• 学ぶこと：ユニットは速い／重いのは別枠
• 手を動かす：遅いテストの原因を分解（依存/I/O/大きいデータ）
• AI：高速化案を箇条書きで出させる
• チェック：遅い→回さない→壊れる、の悪循環😵

第37章：並列実行の落とし穴（順序依存を消す）🧵

• ねらい：テストが順不同でも落ちない
• 学ぶこと：共有状態の排除／テスト独立
• 手を動かす：共有staticをやめる／初期化を見直す
• AI：順序依存になりそうな点を指摘させる
• チェック：テストは“他と関係ない”が理想

第38章：データ生成の整理（毎回手で作らない）🧸✨

• ねらい：Arrange地獄を避ける
• 学ぶこと：ビルダー／ファクトリ／最小データ
• 手を動かす：テストデータ作成を1箇所に集約
• AI：生成ヘルパーの雛形→不要部分を削る
• チェック：データ生成が賢すぎると逆に読めない

第39章：“境界”を増やす（I/Oを薄くする）🚪

• ねらい：中心ロジックがテストしやすくなる
• 学ぶこと：入出力は薄い層へ、中心は純粋に
• 手を動かす：Console入出力を別クラスへ追い出す
• AI：分離後の責務名を提案させる
• チェック：中心にI/Oが混ざるとテストが辛い

第40章：総合演習：推し活グッズ管理①（登録・検索）🎀📦

• ねらい：依存分離＋DI＋テストダブルを使う
• 学ぶこと：UseCaseっぽい単位でテスト
• 手を動かす：登録／検索の仕様→テスト→実装
• AI：仕様からテストケース表を作らせる
• チェック：UI（表示）にロジックが入り始めたら分離

---

Part 6：設計が育つTDD（“壊れにくい形”へ）🏗️✨（41〜46）

第41章：ドメインルールを“型”で守る入門（超やさしく）🧷

• ねらい：無効状態を作りにくくする
• 学ぶこと：値のチェックを入口に寄せる
• 手を動かす：価格・数量のバリデーションをテストから作る
• AI：無効パターン列挙（負数、0、上限、null）
• チェック：ifを増やすより“入れない”が強い

第42章：CQSの超入門（更新と参照を混ぜない）🔀🚫

• ねらい：副作用が読みやすくなる
• 学ぶこと：Command（変える）/ Query（見る）
• 手を動かす：同じメソッドに混ざった責務を分ける
• AI：分離案（命名含む）を提案させる
• チェック：Queryが状態変更してたら事故る😇

第43章：状態が増えたら“状態遷移”で整理（超入門）🧠🗺️

• ねらい：ステータスの抜け漏れが減る
• 学ぶこと：許可される遷移だけ通す
• 手を動かす：グッズの“予約/在庫/販売中”などを簡単に状態化
• AI：状態遷移表のたたき台を作らせる
• チェック：状態が増えたらif地獄になりやすい

第44章：例外の設計（ドメインエラーと外部エラーを分ける）🧯

• ねらい：エラーが暴れない
• 学ぶこと：ユーザーに見せる失敗／運用に出す失敗
• 手を動かす：ドメインエラーをテストで固定
• AI：エラー分類案（リトライ可否）を出させる
• チェック：何でもExceptionは卒業🎓

第45章：リファクタの型（“安全な変形”リストを持つ）🛠️

• ねらい：整理が手早くなる
• 学ぶこと：抽出・インライン・リネーム・移動
• 手を動かす：テストを回しながら3回リファクタ
• AI：候補を出させる→「いちばん小さい」だけやる
• チェック：大改造は小改造の積み重ねで

第46章：推し活グッズ管理②（集計・並び替え・条件検索）📊✨

• ねらい：仕様が増えてもテストで守れる
• 学ぶこと：パラメータ化／境界値／読みやすいテスト
• 手を動かす：集計（合計数・カテゴリ別）をTDD
• AI：検索条件の組合せテストを提案させる
• チェック：テストが重くなったら“責務の見直し”サイン

---

Part 7：BlazorならOK！（UIでもTDDを回す）🎨🧪（47〜49）

第47章：Blazorの“テストしやすい分離”を作る（UIとロジックを分ける）🧩

• ねらい：UIは薄く、ロジックはテスト可能に
• 学ぶこと：コンポーネントは表示＋イベント、処理は別クラスへ
• 手を動かす：同じロジックを“UI外”に移してユニットテスト
• AI：分離案（どの責務をどこへ）を提案させる
• チェック：UIに計算ロジックを入れるほどテストが辛い

第48章：Blazorコンポーネントテスト入門（bUnit想定）🧪🖼️

• ねらい：画面の振る舞いを“自動で”確認できる
• 学ぶこと：レンダリング→イベント→表示変化の確認
• 手を動かす：ボタン押下→表示が変わるテスト
• AI：テストケース（ユーザー操作の流れ）を出させる
• チェック：見た目全部は追わず“重要な振る舞い”に絞る

第49章：Blazor + DI（依存の差し替えをUIでも活かす）🔁

• ねらい：UIから呼ぶサービスを差し替えられる
• 学ぶこと：依存注入されたサービスをテストで差し替える
• 手を動かす：データ取得サービスをスタブ化してUIテスト
• AI：スタブ実装の雛形を出させて最小化
• チェック：ネットワークやDBに繋ぐテストは“別枠”へ

---

Part 8：運用に耐える（続けられるTDD）🏁💪（50）

第50章：卒業制作：推し活グッズ管理③（Blazorで完成）🎓🎉

• ねらい：TDDの流れを最初から最後まで一人で回せる

• 学ぶこと：仕様→テスト→実装→整理→自動化の一連

• 手を動かす：

  • 重要ユースケースをテストで固定
  • UIは必要最低限のテスト（重要導線だけ）
  • 最後に“テスト実行手順”をREADME化

• AI：PRレビュー役として「抜けてる観点」「リファクタ候補」を出させる

• チェック：完成条件＝“テストが仕様として読める＋壊しても直せる安心感”

---

追加：AIに毎章使える“固定プロンプト”例🤖✨

（コピペ用に短くしてます😊）

• 「この仕様のテストケースを、正常/異常/境界値で列挙して」
• 「このテスト、意図が伝わる命名案を3つ出して」
• 「このコード、テストしやすくするための分離案を3つ」
• 「この失敗ログから、原因候補→確認手順を順番に」

---

• 各章に「到達目標」「課題」「提出物（コミット単位）」「小テスト問題」まで付けた“講義台本化”📘
• 推し活グッズ管理を、章ごとに少しずつ育てる“完全な課題設計”🎀
• Visual Studio中心で、操作手順も含めた“実際の教材文章”化🪟🧪