単体テスト(ユニットテスト)とは、関数やメソッドなどプログラムの最小構成単位を個別に検証するテスト手法である。外部依存をモックに置き換え、対象のロジックだけを高速に確認できる。
単体テストの「単体」は言語やフレームワークによって粒度が異なる。関数1つを指すこともあれば、1つのクラスやモジュール全体を指すこともある。共通しているのは「外部 I/O(DB、ネットワーク、ファイルシステム)を排除した状態でテストする」という原則だ。
外部依存はモックやスタブに差し替える。Supabase のクエリ結果をモックオブジェクトで返す、API コールをスタブに置き換えるといった具合だ。これにより実行速度がミリ秒単位に収まり、CI パイプラインで数百〜数千件を毎コミット回せる。
モックは任意のプロパティを持つオブジェクトを返せるため、DB スキーマとの不整合を検出できない。「テストは全件 GREEN だが本番で column does not exist」というインシデントは珍しくない。単体テストはビジネスロジックの検証には強いが、システム境界の整合性は機能テストや E2E テストで補完する必要がある。
TDD(テスト駆動開発)は単体テストを「設計ツール」として活用する開発手法だ。テストを先に書くことで、関数の入出力仕様が実装前に確定する。単体テストの存在が前提となるため、両者は密接に結びついている。


機能テスト(フィーチャーテスト)とは、特定の機能やユースケース単位でシステムの振る舞いを検証するテスト手法である。単体テストより広い範囲を対象とし、複数のモジュールが連携して正しく動作するかを確認する。

E2E テスト(End-to-End テスト)とは、ユーザーの操作を起点にブラウザや API を通じてシステム全体を通過させ、期待どおりの結果が得られるかを検証するテスト手法である。

受け入れテスト(アクセプタンステスト)とは、開発した機能がビジネス要件やユーザーストーリーを満たしているかを、プロダクトオーナーやステークホルダーの視点で検証するテスト手法である。


ベクトルデータベースとは?仕組み・主要製品比較・RAG活用まで徹底解説
TDD(Test-Driven Development)とは、実装コードを書く前にテストを書き、テスト失敗(RED)→実装(GREEN)→リファクタリング(Refactor)の短いサイクルを繰り返す開発手法である。