---
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」](../../docs/04_SPEC/SPEC_03_データセットと受け渡し.md)）
- 実行コマンドは [ENV_04 開発コマンド](../../docs/02_ENV/ENV_04_開発コマンド.md)を参照する

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

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

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

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

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

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

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

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

## 参考 (References)

- [pytest documentation](https://docs.pytest.org/)