テストケース(テストケース)
ソフトウェアの動作を検証する単位。入力 + 期待出力 + 実行手順から成り、ユニット / 結合 / E2E の各層で記述する。Vitest / Playwright / Cypress / Jest が主要フレームワーク。
概要
テストケース(Test Case)は、ソフトウェアの動作を検証する個別の単位を指す。1 つのテストケースは「入力(Input / Setup)+ 期待される出力(Expected)+ 実行手順(Action)」から構成され、ユニットテスト(個別関数) / 結合テスト(複数モジュール) / E2E テスト(エンドツーエンド)の各層で記述される。2026 年現在、JavaScript / TypeScript エコシステムでは Vitest 4 / Playwright 1.59 / Cypress 13.20 / Jest 30 が四大フレームワークで、Bun ランタイムは Bun Test を内蔵し追加インストール不要。
主要テストフレームワーク(2026 年)
JavaScript / TypeScript
| フレームワーク | 形態 | 用途 | 価格 |
|---|---|---|---|
| Vitest 4 | OSS | ユニット + 結合 | 無償 |
| Jest 30 | OSS(Meta) | ユニット + 結合 | 無償 |
| Bun Test | Bun 内蔵 | ユニット + 結合 | 無償 |
| Playwright 1.59 | OSS(Microsoft) | E2E + UI 自動化 | 無償 |
| Cypress 13.20 | OSS / Cloud | E2E + UI | 無償 / Cloud $75/月 |
| Storybook 9 + Test | OSS | コンポーネントテスト | 無償 |
| WebdriverIO | OSS | E2E、Selenium 後継 | 無償 |
Python
| フレームワーク | 用途 |
|---|---|
| pytest | 業界標準、シンプル |
| unittest | 標準ライブラリ |
| nose2 | unittest 拡張 |
Go / Rust / Java / .NET
| 言語 | フレームワーク |
|---|---|
| Go | go test(標準)、testify |
| Rust | cargo test(標準)、proptest |
| Java | JUnit 5 |
| .NET | xUnit / NUnit |
AAA パターン(標準構造)
import { describe, it, expect } from 'vitest';
import { calculateTax } from './tax';
describe('calculateTax', () => {
it('10% 消費税で 100 円から 110 円', () => {
// Arrange(準備)
const price = 100;
const taxRate = 0.10;
// Act(実行)
const result = calculateTax(price, taxRate);
// Assert(検証)
expect(result).toBe(110);
});
it('0 円で 0 円', () => {
expect(calculateTax(0, 0.10)).toBe(0);
});
it('負の価格でエラー', () => {
expect(() => calculateTax(-100, 0.10)).toThrow();
});
});
テストの階層(Test Pyramid)
E2E(少) ← Playwright / Cypress
─────────
結合(中) ← API / DB 統合
─────────────
ユニット(多) ← Vitest / Jest
- ユニット: 個別関数 / クラス、高速 / 安定
- 結合: 複数モジュール、DB / API / ファイル含む
- E2E: ブラウザ自動操作、実環境シミュレーション
主要なテスト技法
- TDD(テスト駆動開発): テスト先 → 実装 → リファクタ
- BDD(振る舞い駆動): Given-When-Then 構文(Cucumber 等)
- Snapshot Testing: 出力スナップショットを保存 / 比較
- Property-Based Testing: 入力をランダム生成(fast-check / Hypothesis)
- Visual Regression: スクリーンショット差分(Chromatic / Percy)
- Mutation Testing: コードに意図的バグ注入で網羅率検証
- Fuzz Testing: 異常入力でクラッシュ検出
カバレッジ指標
| 指標 | 説明 | 目標 |
|---|---|---|
| ステートメント | 実行された行 / 全行 | 80%+ |
| ブランチ | 分岐 if/else | 70%+ |
| 関数 | 呼ばれた関数 / 全関数 | 80%+ |
| 行 | 単純行カバレッジ | 80%+ |
自作.com(jisaku.com)でのテスト構成
apps/jisakucom-api/
├── src/
│ └── domain/value-objects/__tests__/ # Vitest ユニット
├── tests/ # 結合テスト
└── tools/tests/bun-regression/api # 回帰テスト
apps/jisakucom-web/
└── tools/tests/e2e/ # Playwright E2E
Vitest 4 で 696 pass / 84 ファイル / 32 skipped(2026-04-30 実測)。
CI/CD 統合
- GitHub Actions: ./github/workflows/test.yml で push / PR 時実行
- 失敗時 PR ブロック: lefthook + GitHub Branch Protection
- 並列実行: Vitest --threads / Playwright --workers
- キャッシュ: actions/cache@v4 で node_modules / Bun キャッシュ
関連用語との違い
| 用語 | 違い |
|---|---|
| テストスイート | 複数テストケースの集合 |
| アサーション | 期待値の検証文、テストケースの一部 |
| フィクスチャ | テストデータ / セットアップ |
| モック | 依存先の偽実装、テスト用 |
よくある質問
Q1: Vitest と Jest、どちらを選ぶ? A: Vite / Bun ベースなら Vitest(圧倒的に速い)、Create React App 等の伝統的構成なら Jest。新規プロジェクトは Vitest 一択。
Q2: E2E は Playwright と Cypress、どちらが優勢? A: 2024 年以降は Playwright 優勢。並列実行 / マルチブラウザ / モバイル対応 / TypeScript ネイティブで Cypress を圧倒。
Q3: TDD は本当に効果あるか? A: 中〜大規模プロジェクトで顕著。バグ発生率 -50%、リファクタ容易性 +200%、ドキュメント代替効果。学習コスト 1-3 ヶ月、超えれば生産性向上。
まとめ
- ソフトウェア動作の 検証単位、AAA パターンが基本
- 2026 年は Vitest 4 + Playwright 1.59 が二大主流
- Test Pyramid に従い ユニット多 / E2E 少が王道