バックエンド

バックエンドのテスト戦略とは？ユニットテストからE2Eテストまで

公開日: 2024年2月19日著者: mogura

疑問

バックエンドでテストを実装するには、どのような種類のテストがあり、どのように実装すればよいのでしょうか？ユニットテストからE2Eテストまで一緒に学んでいきましょう。

導入

バックエンドのテストは、コードの品質を保証し、バグを早期に発見するための重要な手法です。適切なテスト戦略を実装することで、リファクタリングを安全に行え、コードの信頼性を向上させることができます。

本記事では、テストの種類から、実践的なテストの書き方、テスト駆動開発（TDD）まで、段階的に解説していきます。

テスト戦略のイメージ

解説

1. テストの種類

バックエンドのテストには、ユニットテスト、統合テスト、E2Eテストなど、複数の種類があります。それぞれのテストは異なる目的を持ち、適切に組み合わせることで包括的なテストカバレッジを実現できます。

テストピラミッド

テストピラミッドでは、ユニットテストが最も多く（底辺）、統合テストが中間、E2Eテストが最も少ない（頂点）という構造になっています。ユニットテストは高速で安価、E2Eテストは低速で高コストであるため、この比率が推奨されています。一般的には、ユニットテスト70%、統合テスト20%、E2Eテスト10%の割合が理想的とされています。

ユニットテスト

ユニットテストは、コードの最小単位（関数やメソッド）を独立してテストします。外部依存関係はモックやスタブで置き換え、高速に実行できるようにします。ユニットテストは開発中に頻繁に実行され、リファクタリングの安全性を保証します。

統合テスト

統合テストは、複数のコンポーネント（API、データベース、外部サービスなど）が連携して正しく動作することを確認します。実際のデータベースや外部サービスを使用する場合もあり、ユニットテストより時間がかかりますが、システムの統合性を検証できます。

E2Eテスト

E2Eテストは、システム全体をユーザーの視点からテストします。実際のブラウザやAPIクライアントを使用し、実際のユーザーフローをシミュレートします。最も時間がかかり、保守コストも高いですが、システム全体の動作を確認できます。

テストピラミッドの構造

テストピラミッドは、テストの種類とその理想的な割合を示しています。ユニットテストを基盤とし、統合テストとE2Eテストで補完する構造です。

テストピラミッドの構造：

        /\
       /  \  E2Eテスト（10%）
      /____\
     /      \  統合テスト（20%）
    /________\
   /          \  ユニットテスト（70%）
  /____________\

各レイヤーの特徴：
- ユニットテスト：高速、安価、多数
- 統合テスト：中速、中コスト、中程度の数
- E2Eテスト：低速、高コスト、少数

2. ユニットテスト

ユニットテストは、個々の関数やメソッドを独立してテストする手法です。外部依存関係をモックやスタブで置き換えることで、高速に実行でき、コードの品質を保証します。

Jest を使用したユニットテスト

Jestは、JavaScriptで最も人気のあるテストフレームワークの一つです。テストランナー、アサーション、モック機能が統合されており、設定が簡単で使いやすいです。describe、test、expectなどのAPIを提供し、直感的にテストを書けます。

モックとスタブ

モックは、オブジェクトや関数の動作を模倣し、呼び出しを記録・検証できます。スタブは、特定の値を返すように設定された関数です。これらを使用することで、外部依存関係に依存せずにテストを実行でき、テストの速度と信頼性が向上します。

基本的なユニットテストの例

この例では、シンプルな計算関数のユニットテストを示しています。各関数を独立してテストし、様々なケース（正の数、負の数、エラーケースなど）をカバーしています。

// テスト対象の関数
// utils/calculator.js
function add(a, b) {
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

function divide(a, b) {
  if (b === 0) {
    throw new Error('ゼロで割ることはできません');
  }
  return a / b;
}

module.exports = { add, multiply, divide };

// ユニットテスト
// utils/calculator.test.js
const { add, multiply, divide } = require('./calculator');

describe('Calculator', () => {
  describe('add', () => {
    test('正の数を足す', () => {
      expect(add(2, 3)).toBe(5);
    });
    
    test('負の数を足す', () => {
      expect(add(-2, -3)).toBe(-5);
    });
    
    test('正の数と負の数を足す', () => {
      expect(add(5, -3)).toBe(2);
    });
  });
  
  describe('multiply', () => {
    test('正の数を掛ける', () => {
      expect(multiply(2, 3)).toBe(6);
    });
    
    test('ゼロを掛ける', () => {
      expect(multiply(5, 0)).toBe(0);
    });
  });
  
  describe('divide', () => {
    test('正の数を割る', () => {
      expect(divide(6, 2)).toBe(3);
    });
    
    test('ゼロで割るとエラー', () => {
      expect(() => divide(5, 0)).toThrow('ゼロで割ることはできません');
    });
  });
});

モックを使用したユニットテストの例

この例では、データベースへの依存をモックで置き換えています。実際のデータベースに接続せずにテストを実行でき、テストの速度と独立性が向上します。

// モックを使用したテスト例
// services/userService.js
const db = require('../db');

async function getUserById(id) {
  const user = await db.users.findById(id);
  if (!user) {
    throw new Error('ユーザーが見つかりません');
  }
  return user;
}

module.exports = { getUserById };

// ユニットテスト（モック使用）
// services/userService.test.js
const { getUserById } = require('./userService');
const db = require('../db');

// dbモジュールをモック化
jest.mock('../db');

describe('getUserById', () => {
  test('ユーザーが見つかる場合', async () => {
    const mockUser = { id: 1, name: '山田太郎', email: 'yamada@example.com' };
    db.users.findById.mockResolvedValue(mockUser);
    
    const result = await getUserById(1);
    
    expect(result).toEqual(mockUser);
    expect(db.users.findById).toHaveBeenCalledWith(1);
  });
  
  test('ユーザーが見つからない場合', async () => {
    db.users.findById.mockResolvedValue(null);
    
    await expect(getUserById(999)).rejects.toThrow('ユーザーが見つかりません');
  });
});

3. 統合テスト

統合テストは、複数のコンポーネントが連携して動作することを確認するテストです。API、データベース、外部サービスなどの統合を検証し、システムの統合性を保証します。

API統合テスト

API統合テストは、実際のHTTPリクエストを送信し、レスポンスを検証します。Express.jsなどのフレームワークを使用して、エンドポイントの動作を確認します。認証、バリデーション、エラーハンドリングなど、APIの様々な側面をテストできます。

データベース統合テスト

データベース統合テストは、実際のデータベース（テスト用データベース）を使用して、データの保存、取得、更新、削除をテストします。テスト用データベースを使用し、各テストの前後でデータをクリーンアップすることで、テストの独立性を保ちます。

API統合テストの例

この例では、API統合テストを示しています。実際のHTTPリクエストを送信し、レスポンスを検証しています。テスト用データベースを使用し、各テストの前後でデータをクリーンアップしています。

// API統合テストの例
// tests/integration/users.test.js
const request = require('supertest');
const app = require('../../app');
const db = require('../../db');

describe('Users API Integration Tests', () => {
  beforeEach(async () => {
    // テスト前にデータベースをクリーンアップ
    await db.users.deleteMany({});
  });
  
  afterAll(async () => {
    // テスト後にデータベース接続を閉じる
    await db.close();
  });
  
  describe('POST /api/users', () => {
    test('ユーザーを作成できる', async () => {
      const newUser = {
        name: '山田太郎',
        email: 'yamada@example.com',
        password: 'password123'
      };
      
      const response = await request(app)
        .post('/api/users')
        .send(newUser)
        .expect(201);
      
      expect(response.body).toHaveProperty('id');
      expect(response.body.name).toBe(newUser.name);
      expect(response.body.email).toBe(newUser.email);
      expect(response.body).not.toHaveProperty('password');
    });
    
    test('無効なデータでユーザー作成に失敗する', async () => {
      const invalidUser = {
        name: '',
        email: 'invalid-email'
      };
      
      const response = await request(app)
        .post('/api/users')
        .send(invalidUser)
        .expect(400);
      
      expect(response.body).toHaveProperty('error');
    });
  });
  
  describe('GET /api/users/:id', () => {
    test('ユーザーを取得できる', async () => {
      // テストデータを作成
      const user = await db.users.create({
        name: '山田太郎',
        email: 'yamada@example.com'
      });
      
      const response = await request(app)
        .get(`/api/users/${user.id}`)
        .expect(200);
      
      expect(response.body.id).toBe(user.id);
      expect(response.body.name).toBe(user.name);
    });
    
    test('存在しないユーザーを取得すると404を返す', async () => {
      const response = await request(app)
        .get('/api/users/999')
        .expect(404);
      
      expect(response.body).toHaveProperty('error');
    });
  });
});

データベース統合テストの例

この例では、データベース統合テストを示しています。実際のデータベースを使用して、CRUD操作をテストしています。各テストの前後でデータをクリーンアップすることで、テストの独立性を保っています。

// データベース統合テストの例
// tests/integration/db.test.js
const db = require('../../db');

describe('Database Integration Tests', () => {
  beforeEach(async () => {
    // テスト前にデータベースをクリーンアップ
    await db.users.deleteMany({});
  });
  
  afterAll(async () => {
    await db.close();
  });
  
  test('ユーザーを保存できる', async () => {
    const userData = {
      name: '山田太郎',
      email: 'yamada@example.com',
      password: 'hashed_password'
    };
    
    const user = await db.users.create(userData);
    
    expect(user).toHaveProperty('id');
    expect(user.name).toBe(userData.name);
    expect(user.email).toBe(userData.email);
  });
  
  test('ユーザーを取得できる', async () => {
    const userData = {
      name: '山田太郎',
      email: 'yamada@example.com'
    };
    
    const createdUser = await db.users.create(userData);
    const foundUser = await db.users.findById(createdUser.id);
    
    expect(foundUser).not.toBeNull();
    expect(foundUser.name).toBe(userData.name);
  });
  
  test('ユーザーを更新できる', async () => {
    const user = await db.users.create({
      name: '山田太郎',
      email: 'yamada@example.com'
    });
    
    const updatedUser = await db.users.update(user.id, {
      name: '山田花子'
    });
    
    expect(updatedUser.name).toBe('山田花子');
  });
  
  test('ユーザーを削除できる', async () => {
    const user = await db.users.create({
      name: '山田太郎',
      email: 'yamada@example.com'
    });
    
    await db.users.delete(user.id);
    const foundUser = await db.users.findById(user.id);
    
    expect(foundUser).toBeNull();
  });
});

4. E2Eテスト（End-to-End Test）

E2Eテストは、システム全体をエンドツーエンドでテストする手法です。実際のブラウザやAPIクライアントを使用し、ユーザーの視点からシステムの動作を検証します。

Playwright を使用したE2Eテスト

Playwrightは、Microsoftが開発したE2Eテストフレームワークです。Chrome、Firefox、Safariなどの複数のブラウザをサポートし、高速で信頼性の高いテストを実行できます。自動待機、ネットワークインターセプション、スクリーンショット機能など、豊富な機能を提供します。

E2Eテストの設計

E2Eテストは、すべての機能をテストするのではなく、重要なユーザーフロー（ログイン、商品購入、データ登録など）に焦点を当てます。テストの数は少なく、各テストは独立して実行できるようにします。

Playwrightを使用したE2Eテストの例

この例では、Playwrightを使用したE2Eテストを示しています。実際のブラウザでユーザーフローをシミュレートし、システム全体の動作を検証しています。

// Playwrightを使用したE2Eテストの例
// tests/e2e/user-flow.test.js
const { test, expect } = require('@playwright/test');

test.describe('User Flow E2E Tests', () => {
  test('ユーザー登録からログインまでのフロー', async ({ page }) => {
    // 1. ユーザー登録ページにアクセス
    await page.goto('http://localhost:3000/register');
    
    // 2. フォームに入力
    await page.fill('input[name="name"]', '山田太郎');
    await page.fill('input[name="email"]', 'yamada@example.com');
    await page.fill('input[name="password"]', 'password123');
    
    // 3. 登録ボタンをクリック
    await page.click('button[type="submit"]');
    
    // 4. 登録成功を確認
    await expect(page).toHaveURL(/.*login/);
    await expect(page.locator('.success-message')).toContainText('登録が完了しました');
    
    // 5. ログインページでログイン
    await page.fill('input[name="email"]', 'yamada@example.com');
    await page.fill('input[name="password"]', 'password123');
    await page.click('button[type="submit"]');
    
    // 6. ログイン成功を確認
    await expect(page).toHaveURL(/.*dashboard/);
    await expect(page.locator('.user-name')).toContainText('山田太郎');
  });
  
  test('商品検索と購入のフロー', async ({ page }) => {
    // ログイン
    await page.goto('http://localhost:3000/login');
    await page.fill('input[name="email"]', 'yamada@example.com');
    await page.fill('input[name="password"]', 'password123');
    await page.click('button[type="submit"]');
    
    // 商品検索
    await page.goto('http://localhost:3000/products');
    await page.fill('input[name="search"]', 'ノートパソコン');
    await page.click('button[type="submit"]');
    
    // 検索結果を確認
    await expect(page.locator('.product-item')).toHaveCount(5);
    
    // 商品をクリック
    await page.click('.product-item:first-child');
    
    // カートに追加
    await page.click('button:has-text("カートに追加")');
    
    // カートページに移動
    await page.goto('http://localhost:3000/cart');
    
    // 購入を確認
    await expect(page.locator('.cart-item')).toHaveCount(1);
    await page.click('button:has-text("購入する")');
    
    // 購入完了を確認
    await expect(page.locator('.purchase-success')).toBeVisible();
  });
});

APIのE2Eテストの例

この例では、APIのE2Eテストを示しています。実際のAPIエンドポイントに対してリクエストを送信し、エンドツーエンドのフローを検証しています。

// APIのE2Eテストの例
// tests/e2e/api.test.js
const axios = require('axios');

const API_BASE_URL = 'http://localhost:3000/api';

describe('API E2E Tests', () => {
  let authToken;
  
  beforeAll(async () => {
    // ログインしてトークンを取得
    const response = await axios.post(`${API_BASE_URL}/auth/login`, {
      email: 'test@example.com',
      password: 'password123'
    });
    authToken = response.data.token;
  });
  
  test('ユーザー情報の取得から更新までのフロー', async () => {
    // ユーザー情報を取得
    const getUserResponse = await axios.get(`${API_BASE_URL}/users/me`, {
      headers: { Authorization: `Bearer ${authToken}` }
    });
    
    expect(getUserResponse.status).toBe(200);
    expect(getUserResponse.data).toHaveProperty('id');
    
    const userId = getUserResponse.data.id;
    
    // ユーザー情報を更新
    const updateResponse = await axios.put(
      `${API_BASE_URL}/users/${userId}`,
      { name: '更新された名前' },
      { headers: { Authorization: `Bearer ${authToken}` } }
    );
    
    expect(updateResponse.status).toBe(200);
    expect(updateResponse.data.name).toBe('更新された名前');
    
    // 更新された情報を確認
    const verifyResponse = await axios.get(`${API_BASE_URL}/users/me`, {
      headers: { Authorization: `Bearer ${authToken}` }
    });
    
    expect(verifyResponse.data.name).toBe('更新された名前');
  });
});

5. テスト駆動開発（TDD）

テスト駆動開発（TDD）は、テストを先に書き、そのテストをパスするようにコードを実装する開発手法です。Red-Green-Refactorのサイクルを繰り返すことで、テスト可能で保守しやすいコードを書けます。

TDDのサイクル

TDDのサイクルは以下の3つのステップで構成されます：1. Red（赤）：失敗するテストを書く、2. Green（緑）：テストをパスする最小限のコードを書く、3. Refactor（リファクタリング）：コードを改善する。このサイクルを繰り返すことで、テスト可能で保守しやすいコードを書けます。

TDDのメリット

テストカバレッジの向上: テストを先に書くことで、自然と高いテストカバレッジが得られます。
設計の改善: テストを書くことで、コードの設計を考える機会が増え、より良い設計になります。
リファクタリングの安全性: テストがあることで、リファクタリングを安全に行えます。
ドキュメントとしての機能: テストは、コードの使用方法を示すドキュメントとしても機能します。

TDDの例

TDDの実践例として、ユーザー認証機能を実装する場合、まず認証のテストを書き、その後認証機能を実装します。テストがパスしたら、コードをリファクタリングして改善します。

TDDの実践例

この例では、TDDのサイクルを示しています。まず失敗するテストを書き、次にテストをパスする最小限のコードを書き、最後にコードをリファクタリングして改善しています。

// TDDの例：ユーザー認証機能の実装

// ステップ1: Red - 失敗するテストを書く
// auth.test.js
describe('authenticateUser', () => {
  test('正しい認証情報で認証に成功する', async () => {
    const result = await authenticateUser('test@example.com', 'password123');
    expect(result.success).toBe(true);
    expect(result.user).toHaveProperty('id');
    expect(result.user.email).toBe('test@example.com');
  });
  
  test('間違った認証情報で認証に失敗する', async () => {
    const result = await authenticateUser('test@example.com', 'wrongpassword');
    expect(result.success).toBe(false);
    expect(result.error).toBe('認証に失敗しました');
  });
});

// ステップ2: Green - テストをパスする最小限のコードを書く
// auth.js
async function authenticateUser(email, password) {
  // 最小限の実装
  if (email === 'test@example.com' && password === 'password123') {
    return {
      success: true,
      user: { id: 1, email: 'test@example.com' }
    };
  }
  return {
    success: false,
    error: '認証に失敗しました'
  };
}

// ステップ3: Refactor - コードを改善する
// auth.js（リファクタリング後）
const db = require('./db');
const bcrypt = require('bcrypt');

async function authenticateUser(email, password) {
  const user = await db.users.findOne({ email });
  
  if (!user) {
    return {
      success: false,
      error: '認証に失敗しました'
    };
  }
  
  const isPasswordValid = await bcrypt.compare(password, user.password);
  
  if (!isPasswordValid) {
    return {
      success: false,
      error: '認証に失敗しました'
    };
  }
  
  return {
    success: true,
    user: { id: user.id, email: user.email }
  };
}

6. テストカバレッジ

テストカバレッジは、コードのどの部分がテストされているかを示す指標です。カバレッジを測定することで、テストの不足している部分を特定し、テスト戦略を改善できます。

カバレッジの種類

行カバレッジ（Line Coverage）: 実行されたコード行の割合を示します。
関数カバレッジ（Function Coverage）: 呼び出された関数の割合を示します。
分岐カバレッジ（Branch Coverage）: 実行された分岐（if文など）の割合を示します。
文カバレッジ（Statement Coverage）: 実行された文の割合を示します。

カバレッジの目標

一般的には、80%以上のカバレッジが推奨されますが、プロジェクトの性質によって異なります。重要なビジネスロジックは100%のカバレッジを目指し、単純なユーティリティ関数は低めのカバレッジでも問題ありません。カバレッジは指標の一つであり、テストの質も重要です。

カバレッジの測定設定

この例では、Jestでカバレッジを測定する設定を示しています。カバレッジの閾値を設定し、レポートを生成します。

// Jestでカバレッジを測定する設定
// package.json
{
  "scripts": {
    "test": "jest",
    "test:coverage": "jest --coverage",
    "test:watch": "jest --watch",
    "test:ci": "jest --coverage --ci"
  },
  "jest": {
    "collectCoverageFrom": [
      "src/**/*.js",
      "!src/**/*.test.js",
      "!src/index.js"
    ],
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    },
    "coverageReporters": ["text", "lcov", "html"]
  }
}

// カバレッジレポートの例
// 実行: npm run test:coverage

// 結果:
// --------------------|---------|----------|---------|---------|
// File                 | % Stmts | % Branch | % Funcs | % Lines |
// --------------------|---------|----------|---------|---------|
// All files            |   85.23 |    82.45 |   88.90 |   85.23 |
//  src/                |   85.23 |    82.45 |   88.90 |   85.23 |
//   auth.js            |   90.00 |    85.00 |  100.00 |   90.00 |
//   userService.js     |   80.00 |    80.00 |   75.00 |   80.00 |
// --------------------|---------|----------|---------|---------|

7. ベストプラクティス

テストのベストプラクティスに従うことで、保守しやすく信頼性の高いテストスイートを構築できます。テストの独立性、明確なテスト名、適切なモックの使用などが重要です。

テストの独立性: 各テストは独立して実行でき、他のテストに依存しないようにします。テストの実行順序に依存せず、各テストの前後でデータをクリーンアップします。
明確なテスト名: テスト名は、何をテストしているかが明確に分かるようにします。'should return user when valid id is provided'のように、期待される動作を記述します。
AAAパターン: テストは、Arrange（準備）、Act（実行）、Assert（検証）の3つの部分で構成します。これにより、テストの構造が明確になります。
適切なモックの使用: 外部依存関係は適切にモック化します。ただし、過度なモックは避け、実際の動作に近いテストを書きます。
テストの構造化: describeとtestを使用して、テストを階層的に構造化します。関連するテストをグループ化し、テストの可読性を向上させます。
エッジケースのテスト: 正常系だけでなく、エッジケースやエラーケースもテストします。null、空文字列、負の数、境界値などをテストします。
テストの速度: テストは高速に実行できるようにします。ユニットテストは特に高速に実行し、開発中のフィードバックループを短くします。
テストの保守性: テストコードも本番コードと同様に、保守しやすく読みやすくします。重複を避け、テストヘルパー関数を使用します。
CI/CDへの統合: テストをCI/CDパイプラインに統合し、コードの変更ごとに自動的にテストを実行します。これにより、早期に問題を発見できます。
テストの継続的な改善: テストは一度書けば終わりではなく、継続的に改善します。失敗するテストを修正し、新しい機能に合わせてテストを更新します。

まとめ

バックエンドのテストは、ユニットテスト、統合テスト、E2Eテストを適切に組み合わせることで、包括的なテストカバレッジを実現できます。テスト駆動開発（TDD）を実践することで、テスト可能なコードを書き、リファクタリングを安全に行えるようになります。

適切なモックとスタブの使用、テストの独立性、明確なテスト名など、ベストプラクティスに従うことで、保守しやすいテストスイートを構築できます。継続的にテストを実行し、CI/CDパイプラインに統合することで、コードの品質を保証できます。

実践的なプロジェクトでテストを書き、経験を積むことで、より信頼性の高いバックエンドシステムを構築できるようになります。