By name: 09-test-01-unit-test description: Instructions for unit testing.
単体テストの指示
成果物の配置
- 単体テスト成果物は、
09_Test/01_UnitTestフォルダに配置してください。
単体テストの目的
- 個々の関数・メソッド・クラスが仕様通りに動作することを検証する。
- 不具合を早期に発見し、修正コストを最小化する。
- リファクタリングや変更時のデグレードを防止する。
成果物一覧
| 成果物 | ファイル名例 | 説明 |
|---|---|---|
| 単体テスト仕様書 | UT_仕様書_<機能名>.md |
テスト対象・テスト観点・テストケースを定義 |
| 単体テストコード | test_<モジュール名>.* |
テストフレームワークで実行可能なテストコード |
| テスト結果報告書 | UT_結果_<機能名>.md |
テスト実施結果・合否判定・不具合一覧 |
テスト設計の原則
テスト観点
- 正常系 — 期待される入力に対して正しい出力が返ること
- 異常系 — 不正な入力に対して適切なエラー処理が行われること
- 境界値 — 境界条件（最小値・最大値・0・空文字・null等）での動作
- 同値分割 — 同じ処理結果となる入力グループから代表値を選択
- 状態遷移 — オブジェクトの状態変化が正しく行われること
テストケースの記述項目
各テストケースには以下の情報を記載してください。
| 項目 | 説明 |
|---|---|
| テストID | 一意な識別子（例: UT-001） |
| テスト対象 | 対象の関数・メソッド名 |
| テスト観点 | 正常系 / 異常系 / 境界値 など |
| 前提条件 | テスト実施前に必要な状態・データ |
| 入力値 | テストに使用する入力データ |
| 期待結果 | 正しい出力・動作・状態 |
| 優先度 | 高 / 中 / 低 |
テストコードの規約
命名規則
- テストファイル名:
test_<対象モジュール名>のプレフィックスを付与 - テスト関数名:
test_<テスト対象メソッド>_<条件>_<期待結果>の形式を推奨- 例:
test_calculate_total_with_discount_returns_discounted_price
- 例:
テスト構造（AAA パターン）
各テストは以下の3ステップで構成してください。
- Arrange（準備） — テストデータ・モックの準備
- Act（実行） — テスト対象メソッドの呼び出し
- Assert（検証） — 期待結果との比較・検証
テストの独立性
- 各テストケースは他のテストに依存しないこと
- テスト実行順序に依存しないこと
- テスト間で状態を共有しないこと（必要な場合はセットアップ/ティアダウンで管理）
モック・スタブの利用方針
- 外部依存（DB・API・ファイルシステムなど）はモック/スタブで置き換える
- モックの振る舞いは最小限に定義し、テストの意図を明確にする
- 過度なモックは避け、テストの信頼性を確保する
テストフレームワーク（言語別推奨）
| 言語 | 推奨フレームワーク | 備考 |
|---|---|---|
| Python | pytest | フィクスチャ・パラメータ化テスト対応 |
| JavaScript/TypeScript | Jest / Vitest | モック機能が充実 |
| Java | JUnit 5 | パラメータ化テスト・拡張モデル対応 |
| C# | xUnit / NUnit | .NET標準のテストフレームワーク |
| Go | testing（標準） | テーブル駆動テスト推奨 |
カバレッジ基準
- 行カバレッジ（Line Coverage）: 80%以上を目標
- 分岐カバレッジ（Branch Coverage）: 70%以上を目標
- カバレッジの数値だけを追うのではなく、重要なロジックが網羅されていることを重視する
テスト実施のフロー
- 詳細設計書から対象モジュール・メソッドを特定
- テスト観点を洗い出し、テストケースを設計
- 単体テスト仕様書を作成
- テストコードを実装
- テストを実行し、結果を記録
- 不具合があれば修正後、再テスト
- テスト結果報告書を作成
注意事項
- テストコードも本番コードと同等の品質で記述すること（可読性・保守性）
- ハードコードされたテストデータは定数やフィクスチャとして管理する
- テスト実行は自動化し、CI/CDパイプラインに組み込むことを推奨する
- セキュリティに関わる処理（認証・認可・入力検証など）は重点的にテストする