> 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/codexwoshitana/23-testing.md).

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

## 目的

最小実装を実際に確認し、正しいと判断した振る舞いを自動テストと再現可能な手動手順で固定します。

## テストの基本方針

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

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

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

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

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

## 確認の層

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

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

## 厚くテストする領域

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

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

## `docs/test-plan.md`との接続

テスト計画には、少なくとも次を書きます。

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

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

## 不具合修正

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

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

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

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

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

## 手順

1. 最小実装を人間が操作し、採用する振る舞いを決める
2. `docs/test-plan.md`を実際の確認結果へ更新する
3. Codexに要件と確認結果を基にテスト候補を出させる
4. 重要度に応じてUnit、Integration、E2Eを選ぶ
5. テスト追加後、対象テストと既存テストを実行する
6. 失敗が実装不良、テスト不良、環境制約のどれかを切り分ける
7. 人間が手動確認し、未確認事項を記録する

## Codexに依頼すること

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

## 人間が確認すること

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/23-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.