メインコンテンツまでスキップ

第01章:〜48:上の内容そのまま(Part 1〜6まで)✅

TDDの道

🎯この章のゴール

この章が終わったら、これができればOKだよ〜!💕

  • TDDを「1行」で説明できる✍️✨
  • “テストを読むだけ”で「何を保証してるか」を日本語にできる📘👀
  • 「テスト=仕様(約束)」の感覚がちょっと掴める🤝🧠

まず、TDDを1行で言うと?🧪✨

**TDD=「テスト(仕様)を先に書いて、最小の実装で満たして、読みやすく整える」**だよ🙂💡

ポイントはこれ👇

  • テスト:こう動いてほしい!という“約束”を書く(仕様)
  • 実装:その約束を満たす(まずは最小)
  • 整理:読みやすく、増やしやすく整える(あとで困らない)

「テスト=仕様」ってどういうこと?📘🫶

仕様書って、分厚い文章だと読まれないこと多いよね…🥺💦 でもテストは、機械が毎回チェックしてくれる仕様書なの✨

つまり、テストはこういう役目👇

  • 「この入力なら、こう返す」✅
  • 「この条件なら、こうなる」✅
  • 「ダメな入力は、こう扱う」✅

しかも嬉しいのが、将来コードを変えても…

  • テストが通れば安心😌🌈
  • 落ちたら「どの約束が壊れたか」が分かる😳🔎

よくある勘違い3つ🚫😵‍💫(最初に潰しとく!)

①「テストをたくさん書けば勝ち」じゃない🙅‍♀️

**“仕様として必要な分だけ”**でOK! 増えすぎると読むのも直すのも大変になるよ〜💦

②「実装をキレイにしてからテスト」じゃない🙅‍♀️

TDDは順番が逆! 仕様(テスト)→最小実装→整理の順番がコツ🙂🧼

③「テスト=実装の写し」じゃない🙅‍♀️

テストは“中身の都合”じゃなくて、外から見た約束を書くよ👀✨ (実装の変えやすさが爆上がりする!)


🧱ミニ知識:「良いテスト」ってどんな感じ?

良いテストは、読むとこう思えるやつ👇

  • 「あ、こういう仕様なんだね」📘✨
  • 「落ちた理由がすぐ分かる」🚨🔎
  • 「余計な準備が少ない」🧸

逆に、つらいテストはこう👇

  • 何を保証してるのか分からない😵‍💫
  • 失敗しても原因が見えない🫥
  • 準備コードが長すぎる📦📦📦

🧪手を動かす:テストを読んで「保証してること」を日本語で書こう✍️👀

ここでは“実行”しなくてOK!読むだけでやるよ📘✨ 下のテストを見て、各テストについて次をメモしてね📝💕

  • 保証してること(約束):このテストが守ってる仕様は?
  • 🚫 保証してないこと(約束してない):ここまでは言ってないよね?

例題A:足し算(いちばんシンプル)➕🙂

import { describe, it, expect } from "vitest";
import { add } from "./add";

describe("add", () => {
it("2 + 3 は 5 を返す", () => {
expect(add(2, 3)).toBe(5);
});
});

✅保証してること(例)

  • add(2,3)5 を返す

🚫保証してないこと(例)

  • 小数はどうなる?
  • 文字列が来たら?
  • オーバーフローは?(JS/TS的にどう扱う?)

👉 ここが超大事! テストは「書いた分だけ」しか約束しないよ🙂✨ だからTDDでは、約束を少しずつ増やしていくの💕


例題B:パスワードの最低条件(仕様っぽくなる)🔐✨

import { describe, it, expect } from "vitest";
import { isValidPassword } from "./password";

describe("isValidPassword", () => {
it("8文字以上なら true", () => {
expect(isValidPassword("abcd1234")).toBe(true);
});

it("7文字以下なら false", () => {
expect(isValidPassword("abc1234")).toBe(false);
});
});

✅保証してること(例)

  • 8文字以上のときは true
  • 7文字以下のときは false

🚫保証してないこと(例)

  • 記号が必要かどうか
  • 大文字小文字の条件
  • 空白入りはOKか
  • ちょうど8文字の“中身”が何でもOKか

👉 ここで一言👀 「仕様の穴」=次に足すテスト候補だよ🧪✨


例題C:買い物の合計(境界の匂いがする)🛒🧾

import { describe, it, expect } from "vitest";
import { calcTotal } from "./calcTotal";

describe("calcTotal", () => {
it("100円の商品を2つなら合計は200円", () => {
expect(calcTotal([{ price: 100, qty: 2 }])).toBe(200);
});

it("商品が空なら合計は0円", () => {
expect(calcTotal([])).toBe(0);
});
});

✅保証してること(例)

  • price * qty の合計になってる(少なくともこのケースでは)
  • 空配列は 0

🚫保証してないこと(例)

  • qtyが0やマイナスのとき
  • priceがマイナスのとき
  • 小数(税や端数)
  • たくさん商品があるときの挙動

🎁ミニまとめ:「テストを読む」コツ3つ👀✨

  1. 入力(Given):何を渡してる?🎁
  2. 行動(When):何を呼んでる?📣
  3. 期待(Then):何が欲しい?✅

これだけで、だいぶ“仕様読解”できるようになるよ〜💕


🤖AIの使い方(第1章のおすすめ)🪄✨

AIは「考えの整理」に使うと最強だよ🙂💕

使える頼み方(そのままコピペOK)📎

  • 「このテストが保証してる仕様を日本語で箇条書きにして」📝
  • 「このテストが“保証してないこと”も列挙して」🕳️🔎
  • 「次に追加すると良いテストケースを、境界値→異常系の順に3つ」🚦

でも最後にこれだけ守ってね🙏✨

  • 仕様はAIじゃなくて“テスト”が決める🧪👑
  • AIの提案は「候補」!採用するかは自分で判断🙂

✅チェック(できたら合格〜!)🎉

  • TDDを1行で言えた🙂✍️
  • テストを見て「保証してること」を言葉にできた📘
  • 「保証してないこと」も分かった🕳️🔎
  • “次に足すテスト候補”を思いつけた🧪✨

🧾この章の提出物(ミニでOK)🎀

  1. TDDを1行で(自分の言葉で)✍️

  2. 例題A〜Cについて、各テストの

    • ✅保証してること
    • 🚫保証してないこと をそれぞれ1〜3行で📝
  3. 自分が作りたい機能を1つ選んで、**「約束を3つ」**書く(例:「空なら0」「上限は〜」みたいに)🎯


🆕2026年1月時点の“最新寄りメモ”📌✨

  • TypeScriptは 5.9 が現行の安定版として案内されていて、公式のリリース告知も出てるよ📣 (Microsoft for Developers)
  • Node.js は v24 が Active LTS として扱われてるよ🟢 (Node.js)
  • Vitestは v4 系が大きめの節目で、公式ブログと移行ガイドも更新されてるよ🧪✨ (Vitest)

次の第2章では、いよいよ Red→Green→Refactor を“1回だけ”体験して、TDDの気持ちよさを味わいに行くよ〜🚦😆💖