> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/aineitibu/23-testing.md).

# 23. テスト追加と動作確認

## 目的

最小実装を実際に確認し、正しいと判断した振る舞いを、変更の規模とリスクに応じて自動テストまたは再現可能な手動手順で固定します。

## テストの基本方針

リブログでは、すべての機能を一律にテスト先行で開発しません。探索が必要な画面やAPIでは、まず小さく動かし、人間が利用方法と業務上の妥当性を確認してから重要な振る舞いをテストにします。

```
最小実装 → 動作・業務確認 → テスト追加 → リファクタリング
```

ただし、次の場合はテストを先に書く方法が有効です。

* 不具合の再現条件と期待結果が明確である
* 既存仕様を壊さないことが最重要である
* 入出力の組み合わせを事前に定義できる
* 金額計算や権限判定など、誤りの影響が大きい

TDDか実装先行かを目的化せず、仕様の確度とリスクに応じて選びます。

AIが生成したコードは、自動テストまたは再現可能な手動確認で検証します。どの方法と層で確認するかは、変更の責務、失敗時の影響、仕様の確度、既存テスト構成に合わせて選びます。高リスクな変更、再発を防ぎたい不具合、継続的に守る振る舞いには自動テストを追加します。自動テストを追加しない場合は、理由と手動確認結果を残します。

AIが生成したテストコードもレビュー対象です。テストが実装を追認しているだけではないか、要件から期待値を定めているか、異常系や境界値を確認しているかを人間が確認します。

## 確認の層

| 層                | 主な目的                                  |
| ---------------- | ------------------------------------- |
| Unit Test        | 計算、分岐、Validation、Serviceの振る舞いを高速に確認する |
| Integration Test | DB、HTTP、設定、トランザクションを含む連携を確認する         |
| E2E・画面確認         | 利用者の操作経路と表示を確認する                      |
| 手動確認             | 探索中の使い勝手、見た目、業務上の妥当性を判断する             |

すべてを同じ層で確認せず、失敗原因を特定しやすい最も小さな層を選びます。

Controller、Service、Repositoryなどの名称に限定せず、外部入力の入口、業務判断、外部リソースアクセス、AI処理などの責務ごとにテスト観点を整理します。責務別の具体的な観点は、[責務別レビュー・テストチェックリスト](/engineering-handbook/riburoguno/3-technology-and-architecture/review-checklist.md)を参照します。

## 厚くテストする領域

次の処理は、正常系だけでなく異常系、境界値、権限、再実行、副作用まで確認します。

* 金額、税、請求、ポイントの計算
* 認証、認可、所有者判定
* 日付、時刻、タイムゾーン、期限
* DBの追加、更新、削除、トランザクション
* 外部API、タイムアウト、再試行、重複実行
* 公開APIの互換性とエラー形式
* 個人情報や機密情報の表示、ログ出力

## テスト計画との接続

確認方法は要件と設計の整理後、実装タスクを分解する前に決めます。変更が小さい場合はIssue本文や依頼文へ含め、複数の確認が必要な場合はIssue単位の`test-plan.md`などへ分けます。探索的な変更では暫定の期待結果を記載し、動作確認後に確定内容へ更新します。Issue完了後も継続して使う確認観点は、全体のテスト方針や`current-spec.md`へ同期します。テスト計画には、変更に関係する次の項目を書きます。

1. 前提データと権限
2. 入力または操作
3. 期待する画面、レスポンス、DB状態
4. 実行する自動テスト
5. 手動確認手順
6. 既存機能への影響確認
7. 確認後のデータ復旧方法

手動確認も、「ブラウザで確認する」ではなく、URL、操作、入力、期待表示を再現可能な粒度にします。

## 不具合修正

不具合では、可能な限り次の順で進めます。

```
再現条件の整理 → 再現テスト → 修正 → テスト成功 → 周辺確認
```

再現テストを作れない場合は、理由を記録し、代わりとなる手動手順、ログ、Integration Testなどを残します。テストが修正前に正しく失敗し、修正後に成功することを確認します。

## AIへテストを依頼する際の注意

* 実装コードをそのまま追認する期待値を作らせない
* 要件と確認済みの振る舞いから期待値を導く
* 既存テストの命名、fixture、mock方針へ合わせる
* 正常系だけで完了にしない
* mockしすぎて実際の連携を確認できなくならないようにする
* 時刻、乱数、外部I/Oは再現可能にする
* テストのためだけに本番コードを不自然に公開しない

## 手順

1. 実装前に完了条件から確認方法またはテスト計画の初版を作る
2. 最小実装を人間が操作し、採用する振る舞いを決める
3. 依頼文またはテスト計画を実際の期待結果へ更新する
4. AIに要件と確認結果を基にテスト候補を出させる
5. 重要度に応じてUnit、Integration、E2Eを選ぶ
6. 自動テストを追加した場合は、対象テストと関連する既存テストを実行する
7. 失敗が実装不良、テスト不良、環境制約のどれかを切り分ける
8. 人間が手動確認し、結果と未確認事項を記録する

## AIに依頼すること

* 正常系、異常系、境界値の候補を要件に対応付ける
* 既存のテストパターンに沿って、限定したテストを追加する
* 実行したコマンド、成功・失敗、対象件数を報告する
* 実行できないテストを成功扱いせず、理由を明記する

## 人間が確認すること

* テストの期待値が業務上正しいか
* 実装詳細に依存しすぎていないか
* 高リスク領域の確認が十分か
* 手動確認と自動テストの両方で取りこぼしがないか