テストの基礎

なぜ自動テストを書くのか

コードを書き換えるたびに、画面を手で操作して動作を確かめるのは大変で、見落としも増えます。自動テストは、期待する結果をコードとして書いておき、機械に何度でも検証させる仕組みです。

• 回帰（デグレ）を早く見つける — 既存機能を壊す変更を、その場で検出できます。
• 安心して変更できる — テストが通れば壊していないと分かり、リファクタリングが進めやすくなります。
• 仕様の記録になる — テストは「このコードはこう動くべき」という実行可能な仕様書として読めます。

手作業の確認は遅く再現しづらい一方、自動テストは速く・繰り返せるのが本質的な価値です。

テストの3つの粒度

テストは「どこまでをまとめて確かめるか」で分類されます。粒度が上がるほど現実に近い検証になりますが、遅く・壊れやすくなります。

種類	検証する範囲	速さ	性格
単体（Unit）	関数・クラス単位	速い	多数・細かく検証
結合（Integration）	複数部品の連携やDB接続	中	つなぎ目の不具合を検出
E2E（End-to-End）	利用者の操作全体	遅い	本番に近いが壊れやすい

単体テストはロジック単位を素早く確かめます。結合テストは「DBと正しくやり取りできるか」など部品間の連携を見ます。E2E テストはブラウザ操作などを通して、利用者視点でシステム全体を検証します。

テストピラミッド

3つの粒度をどの割合で書くかの指針がテストピラミッドです。土台に速くて安価な単体テストを多く、上にいくほど少なくします。

        E2E        ← 少数（遅い・壊れやすい）
     結合テスト     ← ほどほど
   単体テスト        ← 多数（速い・安価）

• 下が厚いほど、失敗の原因を素早く特定でき、テスト全体も短時間で回ります。
• 上を厚くしすぎると、実行が遅く、ちょっとした変更で壊れるもろいテスト群になりがちです。

テストの基本形

多くのテストは「準備 → 実行 → 検証」という3段（AAA: Arrange-Act-Assert）で書けます。assert（表明）で期待値と実際の結果を突き合わせます。

// 例：足し算関数のテスト
function add(a, b) {
  return a + b;
}

test("正の数どうしを足せる", () => {
  const result = add(2, 3); // 実行
  expect(result).toBe(5);   // 検証：5 になるはず
});

• Arrange（準備） — 入力やテスト対象を用意する。
• Act（実行） — テストしたい処理を1回呼ぶ。
• Assert（検証） — 結果が期待どおりかを表明する。

良いテストの性質

数を増やせばよいわけではなく、質が重要です。価値あるテストには共通の特徴があります。

• 速い — すぐ終わるから何度でも回せ、開発の妨げになりません。
• 安定（決定的） — 同じコードなら毎回同じ結果。時刻や乱数に左右されないようにします。
• 独立 — テスト同士が順序や共有状態に依存しない。単独で実行できます。
• 1つの振る舞いに集中 — 失敗したとき「何が壊れたか」がすぐ分かります。
• 読みやすい — テスト名と内容で意図が伝わり、仕様書として機能します。

まとめ

自動テストは、コードの正しさを機械的・反復的に検証し、変更時の回帰を素早く見つける土台です。テストは単体・結合・E2E の粒度に分かれ、速く安価な単体テストを厚く、E2E を薄くするテストピラミッドが基本指針になります。そして数より質。速く・安定し・独立し・読みやすいテストこそが、長く役立つ資産になります。