paths: ["tests/", "/test_*.py", "**/conftest.py"]

テスト方針 (Test Policy)

テストコード（tests/**・test_*.py・conftest.py）を追加・編集するときは本ルールに従うこと．

基本方針 (Basic Policy)

フレームワーク: pytest
配置: tests/ 配下に src/tiasdata/ の構造をミラーする
カバレッジ目標: 数値目標なし．代わりに「下記の必須対象は必ず単体テストを書く」を徹底する
臨床データを使うテストは書かない．テストはダミーデータ（tmp_path に作る小さい画像・設定ファイル・目録・ストア）だけで完結させる．手元 PC でも研究室 PC でも同じテストが通ること
研究室 PC の実環境での確認は，テストではなく tiasdata check・tiasdata stats を SSH 経由で実行して行う（SPEC_03「CLI」）
実行コマンドは ENV_04 開発コマンドを参照する

ファイル・関数命名 (Naming)

ファイル: test_<対象モジュール>.py
関数: test_<振る舞い>（例: test_freeze_keeps_past_version_unchanged）
クラス（任意）: Test<クラス名> で振る舞いごとにまとめてよい

必ずテストを書く対象 (Mandatory)

版の凍結: データ・所見を追加・訂正した後も，過去の版から同じ構成・同じ manifest.csv（SHA-256 一致）が得られること．構成が同じなら新しい版を作らないこと．最重要（破れると再現性が無意味になる）
ストア: 同じ中身は 1 つにまとまること．コピー後にハッシュを照合すること．既存のファイルを上書きしないこと．原本（取り込み元）を変更しないこと
取り込み: 2 回実行しても結果が同じであること．取り込み元の想定外の構成（未知のフォルダ・空のフォルダ・想定外の拡張子）で停止すること．途中で失敗したら目録に何も残らないこと
所見の検証と訂正: 未知の値・無効な組み合わせ（例: light_red 以外で normal）を拒否すること．訂正しても古い行が残り，過去の版が古い値を返すこと
バンドル: 書き出したバンドルを open_bundle で読めること．manifest.csv の SHA-256 の不一致・ファイルの欠け・中身の改変を検出すること．バンドルの読み込みが目録なしで動くこと
出力の規則: CLI の出力・ログ・例外メッセージに，対応表の患者 ID・元のファイル名（既定）が現れないこと（ダミーの患者 ID・ファイル名を仕込んで確認する）
設定ファイル: 未知のキー・必須キーの欠落が ValidationError になること
マイグレーション: 空の DB に全マイグレーションを適用でき，PRAGMA user_version が最新になること．再適用しても壊れないこと

テストを必須としない対象 (Optional)

CLI のエントリポイント: 主要な流れ（init → import → freeze → export）を統合テスト 1 本でカバーする
受け渡し（deliver）の SSH 部分: コマンドの組み立てだけを検証する（下記）

モック方針 (Mocking)

SSH・scp はモックする．テストが研究室 PC・計算サーバに接続してはならない（組み立てたコマンド・引数を検証する）
ファイル I/O・SQLite はモックしない．tmp_path に実ファイル・実 DB を作る
日時に依存するテストは日時を引数で渡すか固定する

/implement パイプラインでのテスト (Pipeline)

Phase 1（実装 / coder）: 機能実装 → 人間が動作確認
Phase 2（テスト / tester）: 本方針に従いテストを追加
Phase 3（リファクタ / refactorer）: テストを safety net として品質改善
Phase 4: ドキュメント更新

Phase 2 でテストが書きにくいと感じたら設計が悪いシグナルである．Phase 3 で副作用と純関数を分け直す．

テスト失敗時の運用 (On Failure)

仕様変更による失敗: 先に SPEC を更新してからテストを書き直す
バグ起因の失敗: 修正してから再実行する

参考 (References)

pytest documentation