Skip to main content
KISS TS版YAGNI TS版SoC TS版ADR TS版HC/LC TS版DRY TS版リファクタリング TS版テスタブル TS版TDD TS版エラーモデリング TS版レイヤー TS版MVC TS版依存関係ルール TS版DIP TS版DI TS版Is-a/Has-a TS版SOLID TS版GoFデザインパターン TS版Observer TS版CQS TS版状態機械 TS版不変条件 TS版Entity/VO TS版DDD TS版集約/境界 TS版ドメインイベント TS版モジュラーモノリス TS版ヘキサゴナル TS版クリーンアーキ TS版ACL TS版API Contract TS版SemVer TS版DbC TS版冪等性 TS版CAP定理 TS版Outbox TS版Saga TS版CQRS TS版イベントソーシング TS版BC TS版

TypeScript × TDD（2026）詳細アウトライン： 56章 🧪✨

前提：Windows🪟 / VS Code🧑‍💻 / TypeScript初級〜中級 / TDDは初めて / 設計は超入門 / AI（Copilot/Codex等）導入済み🤖✅ ※章ごとに「🎯目的 / 📚学ぶ / 🧪手を動かす / 🤖AI / ✅チェック」つきだよ💕

Part 1：TDDの地図（まず安心して始める）🗺️🌱（1〜6）​

1. TDDってなに？（1行で言える）🙂​

  • 🎯 目的：TDDを“手順”として説明できる
  • 📚 学ぶ：テスト＝仕様 / 実装＝満たす / 整理＝読みやすく
  • 🧪 手：短いテストを読んで「保証してること」を日本語で書く
  • 🤖 AI：要約→自分の言葉に言い直し
  • ✅ チェック：「テストたくさん書くこと」になってない

2. Red→Green→Refactor を1回体験🚦​

  • 🎯：3ステップを体で覚える
  • 📚：Redの作り方 / Green最小 / Refactorは後で
  • 🧪：足し算関数で1サイクル回す
  • 🤖：失敗ログを貼って原因→次の一手
  • ✅：Greenで作り込みしない

3. “小さく刻む”基本（1テスト＝1約束）🔪​

  • 🎯：仕様を小テストに分解できる
  • 📚：正常→境界→異常の順
  • 🧪：仕様文をテスト3本に分割
  • 🤖：AIに「最小の順番」を3案出させる
  • ✅：1ステップが大きすぎない

4. TDDが向く場所・向かない場所🎯​

  • 🎯：TDDの適用範囲を選べる
  • 📚：純粋ロジック◎ / I/Oは境界で / UIは重要導線だけ
  • 🧪：自分の作りたい機能を“テストしやすさ”で仕分け
  • 🤖：仕分け改善案を出させる
  • ✅：「全部同じやり方」にしてない

5. テストは仕様書（読み物にする）📘​

  • 🎯：読めるテストの感覚を掴む
  • 📚：意図が伝わる命名 / AAAの考え方
  • 🧪：悪いテスト例を「読み物」に直す
  • 🤖：命名案3つ→誤解が少ないの採用
  • ✅：実装の写しになってない

6. AI時代のTDDルール（使い方固定）🤖✅​

  • 🎯：AIを使っても品質が落ちない
  • 📚：AIは案出し係、最終判断はテスト＆意図
  • 🧪：AI案を採用/却下して理由を書く
  • 🤖：毎章同じ“質問テンプレ”を作る
  • ✅：AIの提案が“仕様”になってない

Part 2：環境と習慣（回せる状態を作る）🛠️🪟（7〜14）​

7. プロジェクト作成（フォルダだけ決める）📁​

  • 🎯：迷わない土台を作る
  • 📚：src / tests の分離
  • 🧪：空構成を作ってコミット
  • 🤖：READMEの見出し案を作らせる
  • ✅：ここで設定盛りすぎない

8. Node/TSの方針（最新版より“安定”）🧩​

  • 🎯：環境差で詰まらない
  • 📚：LTS優先、TSは安定版を使う
  • 🧪：node -v / npm -v / tsc -v確認
  • 🤖：エラー文→原因→対処を箇条書き化
  • ✅：バージョン迷子になってない

9. tsconfig最小セット（まず strict）🧷​

  • 🎯：型チェックを味方にする
  • 📚：strictの意味、最低限の設定
  • 🧪：tsconfig最小でビルド＆テストが通る
  • 🤖：設定の意味を“人間語”で説明させる
  • ✅：必要十分に収まってる

10. モジュール（import/export）で迷わない🌿​

  • 🎯：import設定で詰まらない
  • 📚：ESMの基本、拡張子/パスの考え方
  • 🧪：1ファイル→2ファイルに分けてimport
  • 🤖：設定差分を比較表にしてもらう
  • ✅：コピペ設定になってない

11. Vitest導入（成功/失敗を体験）🧪​

  • 🎯：テストが動く
  • 📚：describe/it/expect の最小
  • 🧪：成功テスト1本＋わざと失敗1本
  • 🤖：雛形生成→削って最小化
  • ✅：失敗ログを読める

12. Watch運用（保存→即テスト）🔁​

  • 🎯：TDDが気持ちよく回る
  • 📚：watchの基本、短いサイクル
  • 🧪：Red→Greenをwatchで回す
  • 🤖：運用ルールを短くまとめさせる
  • ✅：回すのが遅くない

13. VS Code Testingビュー（ワンクリック化）🧰​

  • 🎯：心理コストを下げる
  • 📚：1本だけ実行/失敗だけ実行
  • 🧪：テスト選択実行を3回やる
  • 🤖：ショートカットメモを作らせる
  • ✅：コマンド忘れても回せる

14. “1章の粒度”ルール（ブレ防止）📏​

  • 🎯：教材が崩れない
  • 📚：1章＝1ゴール＝1〜3コミット
  • 🧪：コミット規約を作る（例：test: / feat: / refactor:）
  • 🤖：コミット文テンプレを作らせる
  • ✅：章が長編になってない

Part 3：テストの書き方（読みやすさ基礎）📚✨（15〜24）​

15. AAAで書く（型を固定）🧱​

  • 🎯：毎回迷わない
  • 📚：Arrange/Act/Assert
  • 🧪：ぐちゃテスト→AAA整形
  • 🤖：AAA変換案を出させて比較
  • ✅：Assertが散ってない

16. Assert基礎①（数・文字・真偽）✅​

  • 🎯：確認が弱くならない
  • 📚：期待値の置き方、失敗時の読みやすさ
  • 🧪：assertを3種類に書き換えて比較
  • 🤖：観点の抜けを指摘させる
  • ✅：「通るだけ」になってない

17. Assert基礎②（オブジェクト比較）🧸​

  • 🎯：オブジェクト検証ができる
  • 📚：部分一致/完全一致の考え
  • 🧪：同じ仕様を“部分一致”と“完全一致”で書く
  • 🤖：テスト名改善案を出させる
  • ✅：意図に合った比較になってる

18. Assert基礎③（配列・順序・含有）📦​

  • 🎯：配列結果を正しく検証できる
  • 📚：順序が仕様か？を決める
  • 🧪：順序あり/なしのテストを作る
  • 🤖：順序依存の危険点を挙げさせる
  • ✅：仕様が明確になってる

19. 例外・失敗のテスト（異常系入門）🚫​

  • 🎯：失敗も仕様にできる
  • 📚：throw/reject、メッセージの考え方
  • 🧪：無効入力で落ちるテストを書く
  • 🤖：無効入力候補を列挙
  • ✅：失敗の種類が曖昧じゃない

20. テスト名（仕様が読める命名）📝​

  • 🎯：落ちた瞬間に原因が分かる
  • 📚：Given/When/Thenの発想
  • 🧪：テスト名を10個改善
  • 🤖：命名案3つ→誤解少ないの採用
  • ✅：関数名暗記テストじゃない

21. テストデータ最小化（Arrangeを軽く）🧸✨​

  • 🎯：準備が重くならない
  • 📚：意味がある値、最小の例
  • 🧪：Arrangeを半分の行数にする
  • 🤖：冗長ポイントを指摘させる
  • ✅：データが説明できる

22. パラメータ化テスト（ケース増殖の味方）🔁​

  • 🎯：境界値を増やしやすい
  • 📚：増えたら分ける運用
  • 🧪：境界値5ケース追加
  • 🤖：境界値候補リスト作成
  • ✅：読みやすさが保ててる

23. テストの独立性（順序依存を消す）🧵​

  • 🎯：たまに落ちるを防ぐ
  • 📚：共有状態禁止、beforeEachの使い方
  • 🧪：順序依存テストを直す
  • 🤖：共有状態の候補を洗い出し
  • ✅：何回回しても同じ

24. ミニ演習①：カフェ会計（税・端数）☕️🧾​

  • 🎯：基礎でTDDを完走
  • 📚：正常→境界→異常、AAA、命名
  • 🧪：テスト3本→最小実装→整理
  • 🤖：ケース抜け探しだけ依頼
  • ✅：テストが“仕様書”になってる

Part 4：TDDの手筋（設計が育つ）🧠✨（25〜34）​

25. 仮実装（まず通す）🩹​

  • 🎯：Red→Greenを素早く抜ける
  • 📚：仮実装は“仮”
  • 🧪：ベタ実装→次テストで一般化
  • 🤖：永住しそうな箇所の指摘
  • ✅：仮が仮のまま終わってない

26. 三角測量（2例目で一般化）📐​

  • 🎯：一般化のタイミングが分かる
  • 📚：2ケース目の選び方
  • 🧪：2ケース追加→一般化
  • 🤖：次に足すべき例を提案
  • ✅：早すぎ一般化してない

27. 明白な実装（迷いがない時は素直に）🌼​

  • 🎯：儀式化しない
  • 📚：仮/三角/明白の使い分け
  • 🧪：同じ課題を別手で作って比較
  • 🤖：選択理由を説明させる
  • ✅：毎回同じ手になってない

28. 重複のにおい（設計アラーム）👃🚨​

  • 🎯：改善ポイントに気づく
  • 📚：Arrangeが重い＝分離チャンス
  • 🧪：つらいテストを1つ選んで原因を書く
  • 🤖：改善案3つ（最小→中→大）
  • ✅：気合より分離

29. リファクタ安全運転（小さく）🛡️​

  • 🎯：壊さず整理
  • 📚：リネーム→抽出→整理
  • 🧪：3回に分けてリファクタ（毎回テスト）
  • 🤖：候補を出させて“最小だけ”採用
  • ✅：一気に変えてない

30. テスト側リファクタ（読み物として整える）🧹​

  • 🎯：テストが資産になる
  • 📚：共通化しすぎない
  • 🧪：重複を減らしつつ意図を残す
  • 🤖：隠しすぎ警告を出させる
  • ✅：テストが読みやすい

31. ベイビーステップ（詰まらない進め方）👶​

  • 🎯：止まった時に進める
  • 📚：超小ステップ分解
  • 🧪：難仕様を5小テストに分割
  • 🤖：分割案を出させる
  • ✅：作業が細かい

32. 仕様追加の手順（壊れない増やし方）➕​

  • 🎯：機能追加が怖くない
  • 📚：1仕様＝1〜2テストで固定
  • 🧪：割引/上限などを段階追加
  • 🤖：境界値候補を列挙
  • ✅：増えても整理されてる

33. 決定表で整理（if地獄回避）🗂️​

  • 🎯：ルールを見える化
  • 📚：条件×結果の表→テストへ
  • 🧪：決定表→パラメータ化テスト
  • 🤖：表のたたき台作成
  • ✅：条件の抜けが減ってる

34. ミニ演習②：会計（割引・クーポン）🎟️🧾​

  • 🎯：中盤の総合力
  • 📚：決定表、境界値、リファクタ
  • 🧪：3段階で仕様追加→毎回整える
  • 🤖：抜け観点の列挙
  • ✅：テストが増えても読める

Part 5：TypeScriptならでは（型で守る設計入門）🧩🛡️（35〜40）​

35. unionで状態を表す（ifを減らす）🧷​

  • 🎯：状態が増えても崩れない
  • 📚：union/リテラル型
  • 🧪：状態をunion化してテストで固定
  • 🤖：型名候補を出させる
  • ✅：状態追加に強い

36. ブランド型（ID取り違え防止）🏷️​

  • 🎯：string地獄を防ぐ
  • 📚：型で意味を分ける
  • 🧪：UserId/ProductIdを分けてテスト
  • 🤖：命名案の比較
  • ✅：取り違えが起きにくい

37. Result型入門（例外を乱用しない）🧯​

  • 🎯：失敗を仕様にできる
  • 📚：ok/err、呼び出し側の責務
  • 🧪：無効操作をResultで返すテスト
  • 🤖：失敗分類案（ユーザー/システム）
  • ✅：throwだらけになってない

38. 網羅性（exhaustive）で抜け漏れ防止🕳️🚫​

  • 🎯：状態追加のバグを減らす
  • 📚：switchの網羅の考え方
  • 🧪：状態追加→コンパイルで気づける形に
  • 🤖：抜け検知の実装案
  • ✅：追加に強い構造

39. 変換層（外部データに汚染されない）🔄​

  • 🎯：中心モデルを守る
  • 📚：DTO→内部モデル変換をテストで固定
  • 🧪：欠損/型違いの変換テスト
  • 🤖：欠損パターン列挙
  • ✅：中心の型が汚れてない

40. 小さな設計ルール（境界を守る）📏​

  • 🎯：設計が崩れにくくなる
  • 📚：ドメインは外部を直接触らない、の雰囲気
  • 🧪：境界越えを1箇所直す（依存を追い出す）
  • 🤖：依存の向きチェック
  • ✅：責務が混ざってない

Part 6：依存を切る（テストの核心）🔌🎭（41〜48）​

41. 依存って何？（時間・乱数・I/O）⏰🎲​

  • 🎯：不安定の原因を言える
  • 📚：依存一覧化
  • 🧪：自分の機能で依存をリスト化
  • 🤖：抜けの補完
  • ✅：依存が見えてる

42. 依存の注入（関数引数DI）📦➡️​

  • 🎯：差し替え可能になる
  • 📚：newしない/直接呼ばない
  • 🧪：Clock注入で安定テスト
  • 🤖：差分最小修正案
  • ✅：テストが安定した

43. スタブ（返すだけの偽物）🧸​

  • 🎯：外部なしでロジックをテスト
  • 📚：スタブの役割
  • 🧪：DB/HTTPの代わりを作ってテスト
  • 🤖：スタブ設計案
  • ✅：外部なしで回る

44. モック/スパイ（呼ばれ方を仕様に）🎭📣​

  • 🎯：副作用を確認できる
  • 📚：呼ぶ/呼ばない/回数/引数
  • 🧪：通知（ログ/イベント）を呼ぶ条件をテスト
  • 🤖：副作用観点の列挙
  • ✅：呼び方が仕様になってる

45. ファイルI/O境界（本物/偽物の判断）📁​

  • 🎯：遅いテストを増やさない
  • 📚：ユニットは偽物、統合は少数精鋭
  • 🧪：読み込みをアダプタ化してユニットテスト
  • 🤖：本物でやるべき範囲提案
  • ✅：I/O依存が減った

46. 非同期テスト基礎（async/await）⏳​

  • 🎯：PromiseでもTDDできる
  • 📚：resolve/rejectのテスト
  • 🧪：成功/失敗の2テストを書く
  • 🤖：await忘れ等のミス点検
  • ✅：非同期でも安定

47. タイマーとリトライ（遅くしない工夫）⏱️🔁​

  • 🎯：待ち時間でテストが死なない
  • 📚：タイマー制御、疑似時間
  • 🧪：リトライ処理を即検証できる形に
  • 🤖：遅い原因→改善案
  • ✅：テストが速い

48. 乱数の固定（フレーク撲滅の基本）🎲🚫​

  • 🎯：毎回同じ結果にする
  • 📚：乱数源を注入して固定
  • 🧪：乱数を固定して期待値テスト
  • 🤖：不安定ポイント列挙
  • ✅：「たまに落ちる」が消えた

Part 7：外部API（境界→検証→契約）🌐🧪（49〜52）​

49. fetch境界（ネット無しでテスト）🌐​

  • 🎯：外部が落ちてもテストできる
  • 📚：HTTPラッパー、依存注入
  • 🧪：成功/404/500の3ケーステスト
  • 🤖：エラー方針案（リトライ可否）
  • ✅：ネット無しで回る

50. 入力検証（スキーマ/バリデーションの入口）🧷​

  • 🎯：壊れたデータで事故らない
  • 📚：検証→変換→内部型
  • 🧪：欠損/型違いを弾くテスト
  • 🤖：想定すべき欠損例の列挙
  • ✅：入口で守れてる

51. 変換層の契約（DTO→モデルの約束）🤝​

  • 🎯：相手が変わっても被害が小さい
  • 📚：契約＝入出力の約束
  • 🧪：変換層に契約テストを置く
  • 🤖：契約を文章化（READMEひな形）
  • ✅：変更に気づける

52. 後方互換の考え方（壊さず進化）🧬​

  • 🎯：破壊変更で地獄にならない
  • 📚：追加はOK、削除/変更は慎重に
  • 🧪：互換を守るテスト（旧入力もOK）
  • 🤖：互換ポリシー案を作らせる
  • ✅：壊し方が設計できる

Part 8：運用で勝つ（CI・カバレッジ・遅い/不安定対策）🏁✅（53〜55）​

53. カバレッジの正しい距離感（数字に振り回されない）📈​

  • 🎯：カバレッジを道具にする
  • 📚：重要ロジック優先、数字は補助
  • 🧪：重要分岐の穴を埋めるテスト追加
  • 🤖：カバレッジ穴→追加観点を提案
  • ✅：数字だけ追ってない

54. 遅いテストの直し方（継続の生命線）🐢➡️⚡️​

  • 🎯：テストが嫌いにならない
  • 📚：依存分離/データ縮小/タイマー制御
  • 🧪：遅いテストを1つ高速化（体感できるレベル）
  • 🤖：原因候補→改善案の診断
  • ✅：速く回るようになった

55. フレーク（たまに落ちる）を潰す手順💥🧯​

  • 🎯：信頼できるテストにする
  • 📚：共有状態/並列/時間/乱数/外部要因
  • 🧪：フレーク再現→原因特定→修正メモ作成
  • 🤖：原因候補のチェックリスト生成
  • ✅：10回回して0落ち

Part 9：UIは最小必修＋発展（やりすぎない）🖥️✨（56の前に…ここは 56 を卒業制作にしたいので、UIは「必修2章＋発展1章」を このブロック内で 56 の手前に入れる形にします）​

※ごめん！章番号を崩さないために、UIは 56 ではなく 56の直前（＝56は卒業制作）に入れる必要があるので、ここは 章番号を整理して最終確定にするね👇 （＝UIは 56-2〜56-1 みたいにできないから、53〜55を運用にした以上、UIを 41〜52の間に差し込むと流れが崩れるの😵‍💫）

なので、最終確定はこうするね✅

  • 53：UI戦略（必修）
  • 54：DOM/コンポーネントの最小テスト（必修）
  • 55：E2E/ビジュアル（発展・任意）
  • 56：卒業制作 そして「運用（カバレッジ/遅い/フレーク/CI）」は 49〜52に移して、全体の流れを崩さずにバランスを取るよ😊✨

以下が 最終・番号確定版（56章） です👇（内容は上の最適化ポイントそのまま！）

✅最終・番号確定版（56章）詳細アウトライン 🧪✨​

（49〜52＝運用、53〜55＝UI最小、56＝卒業制作）

1〜48：上の内容そのまま（Part 1〜6まで）✅​

（章の中身も上で書いた通りで固定だよ😊）

Part 7：外部API＋運用（境界→検証→契約→運用）🌐✅（49〜52）​

49. fetch境界（ネット無しでテスト）🌐​

  • 🎯：外部が落ちてもテストできる
  • 📚：HTTPラッパー、依存注入
  • 🧪：成功/404/500の3ケーステスト
  • 🤖：エラー方針案（リトライ可否）
  • ✅：ネット無しで回る

50. 入力検証（スキーマ/バリデーションの入口）🧷​

  • 🎯：壊れたデータで事故らない
  • 📚：検証→変換→内部型
  • 🧪：欠損/型違いを弾くテスト
  • 🤖：想定すべき欠損例の列挙
  • ✅：入口で守れてる

51. カバレッジの正しい距離感📈​

  • 🎯：数字に振り回されない
  • 📚：重要ロジック優先、数字は補助
  • 🧪：重要分岐の穴を埋める
  • 🤖：穴→追加観点の提案
  • ✅：数字目的になってない

52. 遅い/不安定（フレーク）を潰す手順🐢💥​

  • 🎯：継続できるテストへ
  • 📚：依存/共有状態/時間/乱数/並列のチェック
  • 🧪：遅いテスト高速化＋フレーク原因メモ作成
  • 🤖：原因候補チェックリスト生成
  • ✅：10回回して0落ち＆速い

Part 8：UIは最小必修＋発展（やりすぎない）🖥️✨（53〜55）​

53. UIテスト戦略（やる/やらないを決める）🧭​

  • 🎯：UIで迷子にならない
  • 📚：重要導線だけ／見た目は最小／ロジックは別でTDD
  • 🧪：重要導線を3つ選び、ユニット/統合/UIに振り分け
  • 🤖：導線案と振り分け案を出させる
  • ✅：UIテストが増えすぎない

54. DOM/コンポーネントの最小テスト（必修）🧱​

  • 🎯：UIでも“壊れにくいテスト”が書ける
  • 📚：セレクタ選び、意図のあるassert、フレーク回避
  • 🧪：クリック→表示変化の最小テストを1本（壊れにくく）
  • 🤖：壊れポイントを指摘させる
  • ✅：安定して通る

55. 発展：E2E/ビジュアルは少数精鋭（任意）⭐️​

  • 🎯：必要な時だけ強くする
  • 📚：E2Eは少数、ビジュアル差分は運用コストも理解
  • 🧪：E2Eシナリオ1本“設計だけ”＋採用基準を書く
  • 🤖：シナリオ案と落とし穴の列挙
  • ✅：やる理由が説明できる

Part 9：卒業制作（TDDで完成まで）🎓🎉（56）​

56. 卒業制作：小アプリを“TDDで完成”＋CI導入✅​

  • 🎯：一人で「仕様→テスト→実装→整理→運用」まで回せる

  • 📚：ここまでの全部（特に“境界分離”と“継続運用”）

  • 🧪：

    • 作品例：推し活グッズ管理🎀 / 家計簿💰 / 学食注文🍙（どれか1つ）
    • 重要ユースケース3つをTDDで完成
    • CIで「テスト＋型チェック」を必須化（GitHub Actions想定）

  • 🤖：PRレビュー役として「抜け観点」「改善案」「命名案」を出させる

  • ✅：

    • ローカルで安定して全テストOK
    • CIでもOK
    • READMEに実行手順がある

必要なら、この56章を「章ごとの提出物（何を提出したら合格か）」「章ごとの所要時間目安」「毎章のAIプロンプト固定テンプレ」まで付けて、さらに教材っぽく整えられるよ😊🧪✨