テスト種別（機能テスト）

機能テストは「システムが意図した通りに動作するか」を検証するテスト群の総称だ。ユニットテスト・統合テスト・E2Eテストはその粒度と対象範囲によって区別されるが、その定義はプロジェクトやチームによって微妙に異なる。重要なのは「どこまでを一単位とするか」という境界の決め方と、各テスト種別のコスト・速度・保証の範囲を踏まえた上で最適な配置を選ぶことだ。

ユニットテストは最小の単位（関数・クラス・モジュール）を外部依存を排除した状態で検証する。実行が速く・フィードバックが早い一方で、「単位」を細かく切りすぎると統合時の問題を捉えられない。何を「単位」とみなすかについてVladimir Khorikovは「共有外部依存（DB・ファイルシステム・API）への依存があるかどうか」で判断するモデルを提案している。

統合テストは複数のコンポーネントを組み合わせた状態で検証する。DBやキャッシュなど実際のインフラを使うテストもここに含まれる場合がある。現代のE2Eテストにおいては、PlaywrightやCypressがブラウザを実際に動かしてユーザーシナリオを検証する。Vitestはユニット・統合テストをブラウザに近い環境でも実行でき、JestとのAPIの互換性を持ちつつより高速だ。

コードレビューで着目するポイント

ユニットテストが実装の内部構造ではなくパブリックAPIを通じて検証しているか
統合テストでモックしている依存が実際の挙動と乖離していないか
E2Eテストがユーザーの操作フローを人間が読める形で記述しているか
テストの実行時間がCI/CDで許容できる範囲に収まっているか
テスト間で共有されたDBのデータが後続テストに影響していないか（テスト隔離）
VitestとPlaywrightの適切な使い分けがなされているか
モックを使ったテストで実際の依存の振る舞いを過度に単純化していないか

典型的なアンチパターン

テストの順序依存: テストAが実行した後にDBのデータが残り、テストBの結果がそれに左右される。各テストはセットアップとクリーンアップを独立して持つべきだ。

スローテストスイート: E2Eテストが数百件あり、CIに30分以上かかる。フィードバックループが遅くなり、テストを無効化する圧力が高まる。E2Eはクリティカルパスのみにとどめ、広いカバレッジは統合テストで担保する。

モックの過剰使用: ユニットテストで全依存をモックし、実際のビジネスロジックより多くのモック設定コードが書かれる。テストが通ってもシステム全体が動くかの保証が低い状態になる。

参考リソース

Vitest https://vitest.dev — 高速なVite-nativeテストランナー
Playwright https://playwright.dev — 信頼性の高いクロスブラウザE2Eテスト
Cypress https://cypress.io — 開発者体験を重視したE2Eテストツール
Testing Library https://testing-library.com — DOM・React・Vueに対応したユーザー視点テスト
Vladimir Khorikov『Unit Testing: Principles, Practices, and Patterns』（Manning、2020）