shibomb

テスト駆動開発(TDD)入門！Jestで学ぶ、バグを減らし自信をつける実践ガイド

はじめに

こんにちは！プログラミングの世界へようこそ。開発を進めていると、「この変更で他の機能が壊れていないかな？」「リリースするのが怖い…」なんて不安を感じたことはありませんか？僕も昔は、変更を加えるたびに手動で動作確認を繰り返し、バグが見つかっては頭を抱える…なんてことが日常茶飯事でした。

そんな不安を解消し、自信を持って開発を進めるための強力な武器が「テスト駆動開発（TDD）」です。TDDは、単にテストを書く技術ではありません。コードの品質を高め、保守しやすく、そして何より開発者自身が安心して前に進むための「開発プロセス」そのものです。

この記事では、JavaScriptのテストフレームワークである「Jest」を使いながら、TDDの基本的な考え方から実践的な手順までを、一歩ずつ丁寧に解説していきます。この記事を読み終える頃には、あなたはTDDのサイクルを自分で回せるようになり、バグを未然に防ぎながら、より品質の高いコードを書くための第一歩を踏み出しているはずです。さあ、一緒に「テストが支えてくれる安心感」を手に入れましょう！

前提知識の確認

新しいことを学ぶ時、何を知っていればいいのか、何は知らなくても大丈夫なのかが分かると、安心して始められますよね。ここでは、TDDを学ぶ上での準備運動をしていきましょう。

必要な基礎知識

この記事は、以下の知識があることを前提に進めていきます。

  • JavaScriptの基本文法: 変数 (let, const)、関数 (function, アロー関数)、条件分岐 (if)、オブジェクト、配列といった基本的な文法が分かっていれば十分です。
  • Node.jsとnpmの基本的な使い方: ターミナル（コマンドプロンプトやPowerShell）で、npm init や npm install といった基本的なコマンドを実行した経験があれば問題ありません。

事前に理解しておきたい概念

専門用語が出てきますが、心配しないでください。ここではざっくりとしたイメージを掴むのが目的です。

  • テストとは？: プログラムが「私たちの期待通りに正しく動くか」を確認する作業のことです。例えば、「1+1を計算する関数は、ちゃんと2を返すか？」を確かめるのがテストです。
  • なぜテストが必要か？: 私たちが書いたコードは、後から機能追加や修正（リファクタリング）が入ります。その時、テストがあれば「変更によって既存の機能が壊れていないこと」を自動で保証してくれます。これが、自信を持ってコードを改修できる大きな安心材料になるのです。

「分からなくても大丈夫」な部分

  • 複雑なテスト理論: TDDにも様々な流派や深い理論がありますが、最初は気にしなくて大丈夫です。まずは手を動かして「テストを先に書く」というリズムを体験することが最も重要です。
  • 他のテストフレームワークの知識: Mocha, Jasmineなど、Jest以外にもテストツールはありますが、今はJestに集中しましょう。一つのツールを使いこなせば、他のツールへの応用も簡単になります。

準備はできましたか？焦らず、自分のペースで進んでいきましょう。

環境構築：最初の一歩

どんな冒険も、まずは装備を整えることから始まります。TDDを実践するための開発環境を準備しましょう。もし途中でうまくいかなくても、それは学びの一部です。落ち着いて一つずつ確認していきましょう。

開発環境の準備（初心者向け解説）

まず、お使いのコンピュータにNode.jsがインストールされているか確認しましょう。ターミナルを開いて、以下のコマンドを実行してください。

node -v
npm -v

v18.12.1 のようにバージョン番号が表示されればOKです。もしインストールされていない場合は、Node.jsの公式サイトからLTS（推奨版）をダウンロードしてインストールしてください。Node.jsをインストールすると、パッケージ管理ツールのnpmも一緒にインストールされます。

コードを書くためのエディタは、Visual Studio Code (VS Code) がおすすめです。無料で高機能なので、多くの開発者に愛用されています。

必要なツールとインストール方法

それでは、TDDを実践するためのプロジェクトを作成し、テストツール「Jest」を導入します。

  1. プロジェクト用フォルダの作成と初期化 好きな場所にプロジェクト用のフォルダ（例: tdd-practice）を作成し、ターミナルでそのフォルダに移動します。そして、以下のコマンドでプロジェクトを初期化します。

    mkdir tdd-practice
cd tdd-practice
npm init -y

    npm init -y を実行すると、プロジェクト管理ファイルである package.json が自動で作成されます。

  2. Jestのインストール 次に、Jestをインストールします。Jestは開発中にしか使わないツールなので、--save-dev オプションを付けます。

    npm install --save-dev jest

  3. テストコマンドの設定 最後に、npm test というコマンドでJestを実行できるように、package.json を編集します。ファイルを開き、"scripts" の部分を以下のように書き換えてください。

    {
  "name": "tdd-practice",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "jest"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "jest": "^29.7.0"
  }
}

これで準備完了です！ npm test と実行すると、Jestが起動し「No tests found」と表示されるはずです。まだテストファイルを何も作っていないので、これは正常な状態です。

環境構築でつまずきやすいポイント

  • コマンドが見つからない (command not found): Node.jsやnpmをインストールした直後にこのエラーが出た場合、ターミナルを再起動してみてください。PCの再起動で解決することもあります。
  • npm installが失敗する: ネットワーク接続が不安定だったり、プロキシ設定が必要な環境だと失敗することがあります。接続を確認し、再度試してみてください。

基本概念の理解

環境が整ったところで、TDDの心臓部である「考え方」を学びましょう。このサイクルを理解することが、TDDマスターへの第一歩です。

核となる考え方

TDDには、「レッド・グリーン・リファクター」という有名な黄金サイクルがあります。プログラミングを、この3つのステップを短い間隔で繰り返しながら進めていくのがTDDの基本です。

  1. レッド (Red): まず、失敗するテストを書きます。これから作ろうとしている機能が「どうあるべきか」をコードで表現します。まだ機能自体は存在しないので、このテストは必ず失敗します（テスト結果が赤くなることから「レッド」と呼ばれます）。

  2. グリーン (Green): 次に、レッドフェーズで書いたテストが成功（パス）する最小限のコードを書きます。ここでは、コードの綺麗さや効率は考えません。とにかくテストをグリーン（成功状態）にすることだけを目指します。

  3. リファクター (Refactor): テストが成功しているという安心材料を元に、書いたコードを綺麗に整理します。変数名を分かりやすくしたり、重複した処理をまとめたりします。この時、テストがグリーンのままであることを常に確認しながら進めます。

このサイクルを、小さな機能単位で何度も何度も繰り返すことで、自然と品質の高いコードが出来上がっていくのです。

テスト駆動開発の3つのステップを視覚的に表現したイラスト。円状の図で、各ステップの色分けと簡単なアイコンで説明。

身近な例での説明

このサイクルを、パズルを組み立てる作業に例えてみましょう。

  1. レッド: 「この角には、青色で空が描かれたピースがはまるはずだ」と、完成形を想像して、はめるべきピースの条件（テスト）を決めます。
  2. グリーン: たくさんのピースの中から、とにかく「青色で空が描かれた角のピース」を探し出して、そこにはめます。他の部分との繋がりはまだ考えません。
  3. リファクター: ピースがはまった状態で、周りのピースとの絵柄のつながりが自然か、向きは合っているかなどを確認し、微調整します。この調整中も、ピースがちゃんとはまっている（テストが通っている）ことは変わりません。

このように、まず「ゴール」を決めてから、そこに向かう最短の道筋を作り、後から道を整備する。これがTDDのリズムです。

「なぜそうなるのか」の理解

なぜわざわざ、失敗するテストから書くのでしょうか？それには、こんなメリットがあります。

  • 目的が明確になる: テストを書くことで、「今から何を作るべきか」がコードレベルで明確になります。仕様の勘違いを防ぎます。
  • 必要最小限の実装になる: テストをパスさせるためだけのコードを書くので、余計な機能（YAGNI - You Ain’t Gonna Need It）を作り込むことがなくなります。
  • 設計が改善される: テストしやすいコードを書こうとすると、自然と機能が小さく分割され、見通しの良い設計になります。
  • リファクタリングへの自信: テストというセーフティネットがあるので、安心してコードの改善に取り組めます。

実践編：手を動かして学ぶ

いよいよ、実際にコードを書きながらTDDのサイクルを体験してみましょう。ここでは、簡単な電卓機能を作るというお題で進めていきます。

まず、プロジェクトフォルダに calculator.js と calculator.test.js という2つのファイルを作成してください。

  • calculator.js: 電卓の機能（実装）を書いていくファイル
  • calculator.test.js: calculator.js の機能が正しいかを検証するテストコードを書くファイル

ステップ1: 基本的な実装

お題：「2つの数値を足し算する add 関数を作る」

1. レッド: 失敗するテストを書く

まず、calculator.test.js にテストコードを書きます。「add という関数は、1と2を引数に取ったら、3を返すはずだ」という期待をコードにします。

// calculator.test.js
const { add } = require('./calculator');

describe('Calculator', () => {
  it('should return 3 when 1 is added to 2', () => {
    expect(add(1, 2)).toBe(3);
  });
});
  • require('./calculator'): calculator.js から add 関数を読み込もうとしています。（まだ存在しません）
  • describe: 関連するテストをまとめるグループです。「電卓」のテストグループであることを示します。
  • it: 一つのテストケースです。「1と2を足したら3が返るべき」というテスト内容を説明しています。
  • expect(add(1, 2)).toBe(3): これがテストの本体です。add(1, 2) の結果が 3 になること (toBe(3)) を期待 (expect) しています。

この状態でターミナルで npm test を実行してみましょう。add 関数が定義されていないので、エラーが出てテストは失敗（レッド）します。これがTDDの始まりです！

2. グリーン: テストをパスする最小限のコードを書く

次に、このテストをパスさせるためだけに、calculator.js に add 関数を実装します。

// calculator.js
function add(a, b) {
  return a + b;
}

module.exports = { add };
  • module.exports: add 関数を他のファイル（calculator.test.js）から require で読み込めるように公開しています。

このコードを追加して、もう一度 npm test を実行してください。今度はテストが成功し、緑色の「PASS」という文字が表示されるはずです。やりましたね！これがグリーンフェーズです。

3. リファクター: コードを整理する

現在の add 関数は非常にシンプルなので、特に整理する点はありません。このステップは、コードが複雑になってきた時に真価を発揮します。今は「リファクタリングの必要はないな」と確認するだけでOKです。

ステップ2: 機能の拡張

お題：「2つの数値を引き算する subtract 関数を追加する」

同じサイクルを繰り返します。

1. レッド: 新しい機能のためのテストを追加する

calculator.test.js に、引き算のテストケースを追加します。

// calculator.test.js
const { add, subtract } = require('./calculator'); // subtract を追加

describe('Calculator', () => {
  it('should return 3 when 1 is added to 2', () => {
    expect(add(1, 2)).toBe(3);
  });

  // 新しいテストケースを追加
  it('should return 2 when 3 is subtracted from 5', () => {
    expect(subtract(5, 3)).toBe(2);
  });
});

npm test を実行すると、subtract が未定義なので新しいテストが失敗し、再びレッドの状態になります。

2. グリーン: テストをパスさせる

calculator.js に subtract 関数を実装します。

// calculator.js
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

module.exports = { add, subtract }; // subtract を追加

npm test を実行すると、両方のテストがパスしてグリーンになります。

3. リファクター: 整理

今回もコードはシンプルなので、リファクタリングは不要です。

ステップ3: 実用的な応用

お題：「add 関数が、マイナスの数値も正しく計算できるようにする」

1. レッド: エッジケースのテストを追加

calculator.test.js の add に関するテストに、新しいケースを追加します。

// calculator.test.js (一部抜粋)
describe('Calculator', () => {
  // ... 既存の add テスト ...
  it('should correctly add negative numbers', () => {
    expect(add(-1, -2)).toBe(-3);
  });

  // ... 既存の subtract テスト ...
});

npm test を実行してみましょう。幸い、私たちの add 関数は既にこのケースに対応できているので、テストはすぐにグリーンになるはずです。これは、最初の実装が偶然にも汎用性の高いものだったという良い例です。TDDは、このように機能の正しさを保証しながら、仕様を網羅していくプロセスでもあります。

ステップ4: チーム開発を意識した改善

テストコードは、未来の自分やチームメンバーへの「仕様書」でもあります。誰が読んでも分かりやすいように記述しましょう。

例えば、describe を使って関連するテストをまとめることで、構造が明確になります。

// calculator.test.js (改善後)
const { add, subtract } = require('./calculator');

describe('Calculator', () => {
  describe('add', () => {
    it('should return 3 when 1 is added to 2', () => {
      expect(add(1, 2)).toBe(3);
    });

    it('should correctly add negative numbers', () => {
      expect(add(-1, -2)).toBe(-3);
    });
  });

  describe('subtract', () => {
    it('should return 2 when 3 is subtracted from 5', () => {
      expect(subtract(5, 3)).toBe(2);
    });
  });
});

このように整理することで、add 関数に関するテスト、subtract 関数に関するテストがひと目で分かりやすくなりました。

実際の開発現場での活用

TDDは練習問題だけでなく、実際の業務でこそ真価を発揮します。現場ではどのように使われているのか、少し覗いてみましょう。

業務での使用例

  • API開発: 「特定のURLにリクエストを送ったら、期待したデータがJSON形式で返ってくるか」といった、APIの振る舞いをテストします。
  • Webフロントエンド: 「ボタンをクリックしたら、モーダルウィンドウが表示されるか」など、ユーザーの操作に対するUIコンポーネントの反応をテストします。
  • 複雑なビジネスロジック: 「ユーザーの購入金額に応じて、正しい割引率が適用されるか」といった、アプリケーションの核となる計算ロジックを厳密にテストします。

TDDによって、これらの複雑な機能が仕様通りに動作することを保証し、安心して機能追加や改修を行えるようになります。

チーム開発でのベストプラクティス

  • コードレビューでの活用: 他の人のコード（プルリクエスト）をレビューする際、まずテストコードを読みます。テストコードはその機能の「仕様書」の役割を果たすため、何を実現しようとしているのかが素早く理解できます。
  • CI/CDへの統合: GitHubやGitLabなどのCI/CD（継続的インテグレーション/継続的デプロイメント）パイプラインに、テストの自動実行を組み込むのが一般的です。これにより、テストが通らないコードが本番環境にデプロイされるのを防ぎます。
  • バグ修正はテストから: バグが見つかった場合、まず「そのバグを再現するテスト」を書きます（このテストは当然失敗します）。そして、そのテストが通るようにコードを修正します。これにより、同じバグの再発を確実に防ぐことができます。

保守性を意識した書き方

テストコードもプロダクトコードと同じくらい大切です。未来の自分やチームメンバーのために、読みやすく保守しやすいテストを書きましょう。

  • 1テスト1アサーション: 1つの it ブロックでは、1つのことだけを検証するのが理想です。これにより、テストが失敗した時に原因を特定しやすくなります。
  • 明確なテスト名: it に書く説明文は、「何を」「どうすると」「どうなるべきか」が分かるように具体的に書きましょう。（例: it('should return a user object when a valid ID is provided')）
  • マジックナンバーを避ける: テストコード内に突然現れる 3 や 100 のような意味の分からない数値（マジックナンバー）は避け、意図が分かるように定数として定義しましょう。

よくあるつまずきポイントと解決策

新しいことに挑戦する時、つまずきはつきものです。ここでは、初心者が陥りがちな壁とその乗り越え方を紹介します。

初心者が陥りやすい問題

  • 「何からテストすればいいかわからない」: 要求される機能を、できるだけ小さな単位に分解してみましょう。「ユーザー登録機能」なら、「①有効なメールアドレスとパスワードなら成功する」「②無効なメールアドレスならエラーになる」「③パスワードが短すぎたらエラーになる」のように、具体的なシナリオに落とし込むと、テストが書きやすくなります。
  • 「テストを書くのが面倒で、時間がかかる」: 最初はそう感じるかもしれません。しかし、TDDで先に少し時間をかけることで、開発終盤での手戻りや、リリース後のバグ修正といった、もっと大きな時間を節約できます。これは「未来への投資」だと考えてみてください。
  • 「テストが脆くなる（Brittle Test）」: 実装の内部構造に依存しすぎたテストを書くと、少しリファクタリングしただけでテストが壊れてしまうことがあります。テストは「関数の内部がどうなっているか」ではなく、「その関数が外から見てどう振る舞うか」を検証するように意識しましょう。

エラーメッセージの読み方

Jestのテスト失敗メッセージは非常に親切です。失敗した時は、焦らずにメッセージをよく読みましょう。

Expected: 3
Received: 2

これは、「期待していた値（Expected）は 3 だったのに、実際に受け取った値（Received）は 2 でしたよ」という意味です。どこで計算を間違えたのかを探る大きなヒントになります。

デバッグの基本的な考え方

テストが失敗した時、問題は「実装コード」にあるのか、それとも「テストコード」自体が間違っているのか、両方の可能性を考えます。

  1. 実装コードを疑う: console.log() を実装コードの途中に入れて、変数の値が期待通りかを確認するのは、シンプルですが非常に有効なデバッグ手法です。
  2. テストコードを疑う: 期待値 (toBe の中身) が間違っていないか、テストの前提条件が正しいかなどを確認します。

継続的な学習のために

TDDの基本をマスターしたら、さらにスキルを伸ばしていくための道筋が見えてきます。

次に学ぶべきこと

  • テストダブル（モック、スタブ）: 外部APIやデータベースなど、他のシステムに依存する部分をテストする際に使うテクニックです。依存部分を偽物（テストダブル）に置き換えることで、テストしたい箇所だけに集中できます。
  • テストの種類: 今回学んだのは「単体テスト（Unit Test）」ですが、他にも複数の機能を組み合わせた「結合テスト（Integration Test）」や、ユーザー操作をシミュレートする「E2Eテスト（End-to-End Test）」などがあります。これらをどう使い分けるかを学ぶと、より網羅的な品質保証ができます。
  • BDD（振る舞い駆動開発）: TDDから派生した開発手法で、ビジネスの要求（振る舞い）を軸に開発を進めます。Gherkin記法（Given-When-Then）などが有名です。

おすすめの学習リソース

  • 公式ドキュメント: Jestのようなツールの公式ドキュメントは、最も正確で最新の情報源です。使い方に迷ったら、まずは公式ドキュメントを参照する習慣をつけましょう。
  • 技術ブログやカンファレンス動画: 第一線で活躍するエンジニアたちが、TDDをどのように実践しているかを知るのは非常に刺激になります。具体的なコード例や、現場ならではの工夫が紹介されていることが多いです。

コミュニティとの関わり方

一人で学び続けるのは大変です。プログラミングの勉強会やオンラインコミュニティに参加して、他の学習者や開発者と交流してみましょう。「このテスト、どう書けばいいと思う？」と相談したり、他の人のコードを見せてもらったりすることで、自分だけでは得られなかった視点や知識を得ることができます。

まとめ：成長のための次のステップ

お疲れ様でした！この記事では、テスト駆動開発（TDD）の基本的な考え方である「レッド・グリーン・リファクター」のサイクルを、Jestを使った具体的なコードと共に学びました。

テストを先に書くことで、開発の目的が明確になり、自信を持ってコードの変更や追加ができるようになる。この「テストがもたらす安心感」を少しでも体感していただけたなら嬉しいです。

TDDは、一度学べば終わりという技術ではありません。日々の開発の中で実践し、試行錯誤を繰り返すことで、徐々にその真価が分かってくる奥深いものです。

今日学んだことを、ぜひあなたの次の小さなプロジェクトで試してみてください。完璧を目指す必要はありません。まずは一つの関数からでも、TDDのサイクルを回してみる。その小さな一歩が、あなたをバグに強く、品質を意識できる優れた開発者へと成長させてくれるはずです。

これからも、学びの楽しさを忘れずに、プログラミングの世界を冒険していってください。応援しています！

#TDD #テスト駆動開発 #Jest #JavaScript #単体テスト #プログラミング初心者

関連記事

【プログラミングで学ぶ節税術】ふるさと納税の控除上限額計算ツールを自作して年間10万円得する思考法を身につけよう！

Deno 2.0実践入門！TypeScriptネイティブで始める、安全でモダンなサーバーサイド開発

【2024年版】Python vs JavaScript vs Go！バックエンド開発、初心者のための最適言語選びガイド