単体テスト

何を「単体」とするか

単体テストの「単体」は言語やフレームワークによって粒度が異なる。関数1つを指すこともあれば、1つのクラスやモジュール全体を指すこともある。共通しているのは「外部 I/O（DB、ネットワーク、ファイルシステム）を排除した状態でテストする」という原則だ。

外部依存はモックやスタブに差し替える。Supabase のクエリ結果をモックオブジェクトで返す、API コールをスタブに置き換えるといった具合だ。これにより実行速度がミリ秒単位に収まり、CI パイプラインで数百〜数千件を毎コミット回せる。

モックの限界

モックは任意のプロパティを持つオブジェクトを返せるため、DB スキーマとの不整合を検出できない。「テストは全件 GREEN だが本番で column does not exist」というインシデントは珍しくない。単体テストはビジネスロジックの検証には強いが、システム境界の整合性は機能テストや E2E テストで補完する必要がある。

TDD との関係

TDD（テスト駆動開発）は単体テストを「設計ツール」として活用する開発手法だ。テストを先に書くことで、関数の入出力仕様が実装前に確定する。単体テストの存在が前提となるため、両者は密接に結びついている。