ソフトウェアテストとは？ユニットテストからE2Eテストまで

テストピラミッド

テストピラミッドは、テストの種類とその比率を視覚化した概念です。

構成：
- ユニットテスト（底辺）: 最も多く書く（70-80%）
- 個々の関数やメソッドをテスト
- 高速で実行可能
- デバッグが容易

- 統合テスト（中間）: 中程度に書く（15-20%）
- 複数のコンポーネントの連携をテスト
- データベースやAPIとの統合をテスト

- E2Eテスト（頂点）: 少なく書く（5-10%）
- ユーザーの操作フロー全体をテスト
- 実行に時間がかかる
- メンテナンスコストが高い

この比率により、高速で信頼性の高いテストスイートを構築できます。

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

Jestは、JavaScriptで最も人気のあるテストフレームワークの一つです。

基本的な使い方：

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

// math.test.js
import { add } from './math';

describe('add関数', () => {
  test('2つの数値を正しく足し算する', () => {
    expect(add(1, 2)).toBe(3);
  });
  
  test('負の数も正しく処理する', () => {
    expect(add(-1, 2)).toBe(1);
  });
});

モックとスタブ

モックとスタブは、外部依存を置き換えてテストを独立させるために使用します。

モック: 関数やオブジェクトの動作を模倣
スタブ: 特定の値を返す簡易的な実装

実践例：

// API呼び出しをモック
jest.mock('./api');
import { fetchUser } from './api';

describe('UserService', () => {
  test('ユーザー情報を取得する', async () => {
    fetchUser.mockResolvedValue({ id: 1, name: 'Alice' });
    
    const user = await getUser(1);
    
    expect(user.name).toBe('Alice');
    expect(fetchUser).toHaveBeenCalledWith(1);
  });
});

テストカバレッジ

テストカバレッジは、コードのどの部分がテストされているかを示す指標です。

カバレッジの種類：
- 行カバレッジ: 実行された行の割合
- 分岐カバレッジ: 実行された分岐の割合
- 関数カバレッジ: 実行された関数の割合
- 文カバレッジ: 実行された文の割合

目標値：
- 一般的に80%以上を目指す
- 100%を目指す必要はない（過度なテストは避ける）

Jestでのカバレッジ確認：

npm test -- --coverage

API統合テスト

API統合テストは、APIエンドポイントとその連携をテストします。

実践例：

// api.test.js
import request from 'supertest';
import app from './app';

describe('API統合テスト', () => {
  test('GET /api/users が正しく動作する', async () => {
    const response = await request(app)
      .get('/api/users')
      .expect(200);
    
    expect(response.body).toHaveLength(3);
    expect(response.body[0]).toHaveProperty('id');
    expect(response.body[0]).toHaveProperty('name');
  });
  
  test('POST /api/users がユーザーを作成する', async () => {
    const newUser = { name: 'Bob', email: 'bob@example.com' };
    
    const response = await request(app)
      .post('/api/users')
      .send(newUser)
      .expect(201);
    
    expect(response.body).toHaveProperty('id');
    expect(response.body.name).toBe('Bob');
  });
});

データベース統合テスト

データベース統合テストは、データベースとの連携をテストします。

実践例：

// database.test.js
import { db } from './database';

describe('データベース統合テスト', () => {
  beforeEach(async () => {
    await db.migrate.rollback();
    await db.migrate.latest();
  });
  
  afterEach(async () => {
    await db.migrate.rollback();
  });
  
  test('ユーザーをデータベースに保存できる', async () => {
    const user = await db('users').insert({
      name: 'Alice',
      email: 'alice@example.com'
    }).returning('*');
    
    expect(user[0]).toHaveProperty('id');
    expect(user[0].name).toBe('Alice');
  });
});

Playwright を使用したE2Eテスト

Playwrightは、Microsoftが開発したE2Eテストフレームワークです。

特徴：
- 複数のブラウザをサポート（Chrome、Firefox、Safari）
- 自動待機機能
- スクリーンショットとビデオ記録
- 並列実行が可能

実践例：

// e2e/login.spec.js
import { test, expect } from '@playwright/test';

test('ログインフローのテスト', async ({ page }) => {
  await page.goto('https://example.com/login');
  
  await page.fill('#email', 'user@example.com');
  await page.fill('#password', 'password123');
  await page.click('button[type="submit"]');
  
  await expect(page).toHaveURL('https://example.com/dashboard');
  await expect(page.locator('h1')).toContainText('ダッシュボード');
});

Cypress を使用したE2Eテスト

Cypressは、人気のあるE2Eテストフレームワークです。

特徴：
- 開発者フレンドリーなAPI
- タイムトラベル機能
- リアルタイムでのテスト実行
- デバッグが容易

実践例：

// cypress/e2e/login.cy.js
describe('ログインフロー', () => {
  it('ユーザーがログインできる', () => {
    cy.visit('/login');
    cy.get('#email').type('user@example.com');
    cy.get('#password').type('password123');
    cy.get('button[type="submit"]').click();
    
    cy.url().should('include', '/dashboard');
    cy.contains('ダッシュボード').should('be.visible');
  });
});

TDDのサイクル

TDDは、以下の3つのステップを繰り返します：

1. Red（赤）: テストを書き、実行して失敗させる
- 実装する機能のテストを書く
- テストが失敗することを確認

2. Green（緑）: テストが通る最小限の実装を書く
- テストが通る最小限のコードを書く
- テストが成功することを確認

3. Refactor（リファクタリング）: コードを改善する
- コードの品質を向上させる
- テストが引き続き成功することを確認

このサイクルを繰り返すことで、段階的に機能を実装します。

TDDの例

TDDの実践例：

ステップ1: テストを書く（Red）

// calculator.test.js
describe('Calculator', () => {
  test('2つの数値を足し算できる', () => {
    const calc = new Calculator();
    expect(calc.add(2, 3)).toBe(5);
  });
});

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

// より良い実装に改善
class Calculator {
  add(...numbers) {
    return numbers.reduce((sum, num) => sum + num, 0);
  }
}

スナップショットテストの実装

Jestを使用したスナップショットテストの例：

// Component.test.js
import { render } from '@testing-library/react';
import Component from './Component';

describe('Component', () => {
  test('スナップショットが一致する', () => {
    const { container } = render(<Component name="Alice" />);
    expect(container).toMatchSnapshot();
  });
});

AAAパターン（Arrange-Act-Assert）

AAAパターンは、テストを3つのセクションに分けるパターンです。

構造：
- Arrange（準備）: テストに必要なデータやオブジェクトを準備
- Act（実行）: テスト対象のメソッドを実行
- Assert（検証）: 結果を検証

実践例：

test('ユーザーを追加できる', () => {
  // Arrange（準備）
  const userService = new UserService();
  const newUser = { name: 'Alice', email: 'alice@example.com' };
  
  // Act（実行）
  const result = userService.addUser(newUser);
  
  // Assert（検証）
  expect(result).toHaveProperty('id');
  expect(result.name).toBe('Alice');
});

テストの独立性

テストは、他のテストに依存せず、任意の順序で実行できる必要があります。

実践方法：
- 各テストの前に必要なデータを準備（beforeEach）
- 各テストの後にクリーンアップ（afterEach）
- グローバルな状態を変更しない
- テスト間でデータを共有しない

実践例：

describe('UserService', () => {
  let userService;
  
  beforeEach(() => {
    userService = new UserService();
  });
  
  afterEach(() => {
    userService.clear();
  });
  
  test('ユーザーを追加できる', () => {
    // テスト
  });
});

明確なテスト名

テスト名は、何をテストしているかを明確に示す必要があります。

良いテスト名の例：
- ユーザーを追加できる
- 無効なメールアドレスでエラーを返す
- 空の配列を返す

悪いテスト名の例：
- test1
- ユーザーテスト
- 動作する

命名パターン：
- [条件]で[期待される動作]
- [メソッド名]は[期待される動作]

GitHub Actionsでのテスト実行

GitHub Actionsを使用したテスト実行の例：

# .github/workflows/test.yml
name: Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: '18'
    - run: npm ci
    - run: npm test
    - run: npm run test:coverage

テストのメンテナンス方法

テストのメンテナンスを効率的に行う方法：

実践方法：
- 壊れたテストをすぐに修正: テストが失敗した場合、すぐに修正する
- 不要なテストを削除: 機能が削除された場合、関連するテストも削除
- テストをリファクタリング: 重複したテストを統合
- テストのドキュメント化: 複雑なテストにはコメントを追加
- 定期的なレビュー: テストスイートを定期的にレビュー

注意点：
- テストの削除は慎重に行う
- テストの目的を理解してから変更する