単体テストの考え方完全ガイド - 目的・設計原則・テストケースの作り方を徹底解説

1
2
3
4
5
6
7
8
9

リファクタリング前:
  - 既存機能が壊れないか不安
  - 手動テストに時間がかかる
  - 結果的に「動いているから触らない」状態に

リファクタリング後（テストあり）:
  - テストが緑なら問題なし
  - 数秒で検証完了
  - 積極的にコードを改善できる

1
2
3
4
5

テストなしの場合:
  バグ報告 → アプリ全体の調査 → 原因特定（数時間〜数日）

テストありの場合:
  テスト失敗 → 失敗したテストを確認 → 原因特定（数分）

1
2
3
4

テストケース名: 「18歳以上の場合に成人と判定される」
  → この関数は年齢を受け取り、18歳以上で成人と判定することがわかる
  → 境界値が18歳であることがわかる
  → ドキュメントと違い、常に最新の仕様を反映する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

テストしにくいコード:
  - グローバル状態に依存
  - 1つのメソッドで多くのことをしている
  - 外部システムと密結合

↓ テストを書こうとすると...

改善される設計:
  - 依存性注入の導入
  - 単一責任の原則に従う
  - インターフェースによる抽象化

1
2
3
4
5
6
7
8
9

推奨される実行時間:
  - 1つのテスト: 10ms以下
  - テストスイート全体: 数秒〜数分以内

遅くなる原因:
  - 実際のデータベースアクセス
  - ネットワーク通信
  - ファイルI/O
  - sleep/wait処理

1
2
3
4
5
6
7
8

悪い例:
  テストA → テストB → テストC（順番に依存）
  テストAでデータ作成 → テストBで参照 → テストCで削除

良い例:
  各テストが自分の必要なデータを準備
  各テストが自分の後始末を行う
  どの順番で実行しても同じ結果

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

再現性を損なう要因:
  - 現在時刻への依存（Date.now()、LocalDate.now()）
  - 乱数への依存
  - 外部APIの状態
  - 実行順序への依存

対策:
  - 時刻はテスト用に固定値を注入
  - 乱数はシードを固定
  - 外部依存はテストダブルで置換

1
2
3
4
5
6
7

悪い例:
  console.log("結果を確認してください: " + result)
  → 人間が目視で確認が必要

良い例:
  assert(result === expected)
  → 自動で成功/失敗を判定

1
2
3
4
5
6
7

理想的なタイミング:
  - TDD: 実装前にテストを書く
  - 最低限: 実装と同時にテストを書く

避けるべきパターン:
  - プロジェクト終盤にまとめてテストを書く
  - リリース後にテストを追加する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Arrange（準備）:
  - テスト対象のオブジェクトを生成
  - 必要なテストデータを準備
  - モック/スタブの設定

Act（実行）:
  - テスト対象のメソッドを呼び出す
  - 原則として1回の呼び出しのみ

Assert（検証）:
  - 期待する結果と実際の結果を比較
  - 例外のスローを検証

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 疑似コード（言語非依存）
function testCalculateDiscount() {
    // Arrange（準備）
    customer = createPremiumCustomer()
    order = createOrder(amount: 10000)
    calculator = new DiscountCalculator()
    
    // Act（実行）
    discount = calculator.calculate(customer, order)
    
    // Assert（検証）
    assertEqual(discount, 1000)  // 10%割引
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

悪い例（複数の振る舞いを検証）:
  function testUserRegistration() {
      // ユーザー作成の検証
      user = createUser(name: "John")
      assertNotNull(user)
      
      // メール送信の検証
      assertEmailSent(to: user.email)
      
      // ログ出力の検証
      assertLogContains("User created")
  }
  
  問題点:
    - 最初のアサーションで失敗すると、後続は評価されない
    - 何をテストしているのかわかりにくい

良い例（1つの振る舞いを検証）:
  function testCreateUserReturnsValidUser() {
      user = createUser(name: "John")
      assertNotNull(user)
      assertEqual(user.name, "John")
  }
  
  function testCreateUserSendsWelcomeEmail() {
      user = createUser(name: "John")
      assertEmailSent(to: user.email)
  }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

推奨されるパターン:
  1. should_[期待する動作]_when_[条件]
     例: should_return_zero_when_input_is_empty
     
  2. [メソッド名]_[条件]_[期待結果]
     例: calculateTotal_withEmptyCart_returnsZero
     
  3. 日本語での記述（日本語対応の環境）
     例: 空のカートで合計金額を計算すると0円が返される

避けるべきパターン:
  - test1, test2（何をテストしているか不明）
  - testCalculate（どのケースか不明）
  - 実装の詳細を含む名前

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

仕様: 年齢が18歳以上で成人と判定

境界値:
  - 17歳（境界の直前、未成年）
  - 18歳（境界上、成人）
  - 19歳（境界の直後、成人）

テストケース:
  年齢17 → 未成年
  年齢18 → 成人
  年齢19 → 成人

1
2
3
4
5
6
7
8

関数: リストの最大値を取得する

テストすべきエッジケース:
  - 空のリスト → 例外 or null
  - 1要素のリスト → その要素を返す
  - 全要素が同じ値 → その値を返す
  - 負の値を含む → 正しく比較される
  - 最大値が複数存在 → いずれかを返す

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

悪い例（依存がハードコード）:
  class OrderService {
      repository = new DatabaseRepository()  // 固定
      
      function createOrder(data) {
          return repository.save(data)
      }
  }
  
  問題点:
    - テスト時も実際のDBにアクセスしてしまう
    - DBがないとテストできない

良い例（依存性注入）:
  class OrderService {
      constructor(repository) {  // 外部から注入
          this.repository = repository
      }
      
      function createOrder(data) {
          return repository.save(data)
      }
  }
  
  利点:
    - テスト時はモックを注入できる
    - 本番時は実際のDBリポジトリを注入

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

悪い例（複数の責任）:
  class UserManager {
      createUser(data)
      sendEmail(user)
      generateReport()
      validateCreditCard()
  }
  
  問題点:
    - テストの準備が複雑
    - 関係ない機能の変更で影響を受ける

良い例（責任の分離）:
  class UserService { createUser(data) }
  class EmailService { sendEmail(user) }
  class ReportGenerator { generateReport() }
  class PaymentValidator { validateCreditCard() }
  
  利点:
    - 各クラスを独立してテスト可能
    - 変更の影響範囲が限定される

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

悪い例（計算と副作用が混在）:
  function processOrder(order) {
      total = calculateTotal(order.items)
      tax = total * 0.1
      finalPrice = total + tax
      
      database.save(order, finalPrice)  // 副作用
      email.send(order.customer)        // 副作用
      
      return finalPrice
  }

良い例（分離）:
  // 純粋な計算（テストしやすい）
  function calculateFinalPrice(items) {
      total = calculateTotal(items)
      tax = total * 0.1
      return total + tax
  }
  
  // 副作用を含む調整役
  function processOrder(order) {
      finalPrice = calculateFinalPrice(order.items)
      database.save(order, finalPrice)
      email.send(order.customer)
      return finalPrice
  }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

典型的なCIパイプライン:
  
  1. コードチェックアウト
  2. 依存関係のインストール
  3. 静的解析（リンター）
  4. 単体テスト実行 ← ここ
  5. カバレッジレポート生成
  6. 結合テスト（必要に応じて）
  7. ビルド
  8. デプロイ（条件付き）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

カバレッジの種類:
  - 行カバレッジ: 実行された行の割合
  - 分岐カバレッジ: 実行された分岐の割合
  - 条件カバレッジ: 各条件の真偽両方をテストした割合

カバレッジの落とし穴:
  - 100%でもバグがないとは限らない
  - 数値を上げることが目的化する危険性
  - 意味のないテストでも数値は上がる

推奨アプローチ:
  - 目安として70-80%を目標に
  - 重要なビジネスロジックは重点的にカバー
  - カバレッジより「意味のあるテスト」を優先

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

悪い例:
  function testCalculateTotal() {
      cart = new ShoppingCart()
      cart.addItem(item)
      
      // 内部実装に依存
      assert(cart._items.length == 1)
      assert(cart._totalCache == 100)
  }

問題点:
  - privateフィールドに直接アクセス
  - 内部の実装方法を変更するとテストが壊れる
  - リファクタリングを阻害する

良い例:
  function testCalculateTotal() {
      cart = new ShoppingCart()
      cart.addItem(item)
      
      // 公開インターフェースを検証
      assert(cart.getItemCount() == 1)
      assert(cart.getTotal() == 100)
  }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

悪い例:
  function testProcessOrder() {
      // すべてをモック化
      mockRepository = createMock()
      mockValidator = createMock()
      mockCalculator = createMock()
      mockNotifier = createMock()
      
      mockCalculator.returns(100)
      mockValidator.returns(true)
      
      service = new OrderService(
          mockRepository, mockValidator, 
          mockCalculator, mockNotifier
      )
      
      result = service.process(order)
      
      assert(result == 100)
  }

問題点:
  - テストが本番コードの構造に完全に依存
  - モックの設定が複雑で読みにくい
  - 実際の連携をテストしていない

良い例:
  function testProcessOrder() {
      // 外部システムのみモック化
      mockPaymentGateway = createMock()
      
      service = new OrderService(mockPaymentGateway)
      result = service.process(order)
      
      assert(result.status == "completed")
  }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

悪い例:
  function testGetUserDisplayName() {
      user = service.getUser(id)
      
      // 完全一致で検証
      assert(user.displayName == "John Smith (Premium Member since 2020)")
  }

問題点:
  - 日付フォーマットの変更で壊れる
  - 表現の微調整で壊れる
  - 本質的でない変更に敏感

良い例:
  function testGetUserDisplayName() {
      user = service.getUser(id)
      
      // 本質的な部分のみ検証
      assert(user.displayName.contains("John Smith"))
      assert(user.isPremium == true)
  }

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

症状:
  - 「締め切りが近いのでテストは後で」
  - 結果的に永遠に書かれない
  
原因:
  - テストを「追加作業」と捉えている
  - 短期的なコスト削減を優先
  
対策:
  - テストは実装の一部と認識する
  - 「テストなしでは完了ではない」という基準を設ける
  - 最初は重要な部分だけでも書く習慣をつける

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

症状:
  - リファクタリングのたびにテストを修正
  - テストの修正に実装以上の時間がかかる
  
原因:
  - 実装の詳細に依存したテスト
  - 過度なモック化
  
対策:
  - 公開インターフェースのみをテスト
  - モックは共有依存（DB、外部API）に限定
  - テストと実装を同時に設計

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

症状:
  - カバレッジは高いのにバグが発生
  - テストをパスしても本番で問題が起きる
  
原因:
  - ハッピーパスのみをテスト
  - 境界値やエッジケースの不足
  - アサーションが不十分
  
対策:
  - 境界値分析を適用
  - エラーケースを積極的にテスト
  - 「このテストは何を守っているか」を常に意識

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

症状:
  - テストスイートの実行に数十分かかる
  - 開発者がテストを実行しなくなる
  
原因:
  - 単体テストで実際のDB/ネットワークを使用
  - テストの粒度が大きすぎる
  
対策:
  - 外部依存はテストダブルで置換
  - テストピラミッドを意識（単体テストを多く、E2Eを少なく）
  - 遅いテストは別のテストスイートに分離

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

1. 特性化テスト（Characterization Test）を書く
   - 現在の動作を記録するテスト
   - 正しいかどうかは問わない
   
2. テストが通ることを確認
   - 現状の動作がドキュメント化される
   
3. リファクタリングを行う
   - テストが安全網になる
   
4. テストを仕様に合わせて修正
   - 特性化テストを正規のテストに変換