PostgreSQL 拡張（例: pgvector）の型・演算子・制約まで検証したいリポジトリ層テストでは、共有ローカル DB や素の PostgreSQL イメージではなく、Testcontainers などで本番相当の拡張入りイメージを起動し、実際の migration を適用してからテストする。

判断基準:

• DB 固有の型、拡張演算子、制約、JOIN、transaction を検証したい場合は integration test として実 DB を使う。mock では SQL と DB 拡張の破綻を検出できない。
• 複数 checkout / worktree / CI 並列実行で干渉を避けたい場合は、固定ポート・共有 DB 名に依存せず、テスト実行ごとにコンテナとランダムマップポートを払い出す。
• 拡張型を使う migration がある場合、素の DB イメージでは type does not exist や演算子未定義で落ちる。拡張がインストール済みのイメージを使い、CREATE EXTENSION IF NOT EXISTS ... が拡張型カラム作成より前に適用されることを確認する。
• 通常の unit test と Docker 依存の integration test は build tag や専用 test target で分離する。普段の高速テストに Docker 起動コストやネットワーク pull 依存を混ぜない。

検証方法: 初回は test cache を避けて -count=1 相当で実コンテナを起動し、migration 適用、拡張型への insert/upsert、拡張演算子を使う query まで通す。拡張が pgvector の場合は、カラム次元と同じ長さの非ゼロベクトルを使い、類似度順が期待通りになることを確認すると、型・scan・演算子の全てを一度に検証できる。