この記事でわかること
- 単体試験で「分岐網羅」を実現する考え方
- 設計書から分岐を抽出する方法
- テストマトリクスを“ノード単位”で分割し、シンプルに保つ方法
背景：分岐網羅しろと言われて詰んだ話
業務で単体試験を書くことになり、上長から
「分岐をしっかり網羅してね」
と言われて、どないしよ
みたいな感じでした
試しこと：この記事を読んでマトリクスを導入
当時はマトリクスという発想すらなかったのですが
この参考記事のおかげで道が開けました👇
🔗 https://zenn.dev/unsese/articles/bd6b2ac52afe687ca97d
テストマトリクスで抜け漏れが見える化できる
という考え方に救われました🙏
分岐網羅とは？
発生し得る すべての条件分岐 をテストで通すこと
途中から案件に入って設計書はほとんど出来上がっており、
そもそもの実装に不具合があれば、見抜くことができないと思い、設計書ベースで行いました。
設計書 → 分岐抽出の手順
私は以下のように整理しました👇
設計書の判断処理を
↓
「ノード」（判断単位）に分割
↓
各ノードの入力条件 × 結果をマトリクス化
実例：3つの判断ノードがある設計書の場合
● Aノード（入力チェック）
| No | 入力条件 | 設計上の結果 | 分岐 |
|---|---|---|---|
| A-01 | 正常 | 次ノードへ | pass |
| A-02 | 空 | エラー返却 | fail1 |
| A-03 | 不正フォーマット | エラー返却 | fail2 |
● Bノード（計算ロジック）
| No | 値 | 結果 | 分岐 |
|---|---|---|---|
| B-01 | 正常範囲 | 正常動作 | pass |
| B-02 | 上限超え | エラー返却 | fail |
● Cノード（最終判定）
| No | 中間値 | 判定 | 分岐 |
|---|---|---|---|
| C-01 | OK | true | pass |
| C-02 | NG | false | fail |
✅ 設計書ベースにして良かったこと
| ソースベース | 設計書ベース |
|---|---|
| 実装依存になりがち | 本来あるべき仕様をテストできる |
| 後から仕様追加が発覚 | 最初から仕様の全景が見える |
| 見落としが起きやすい | 抜け漏れ防止になる |
| レビューで揉めがち | 「設計通り」で説明できる |
→ 仕様の品質保証にもつながるのが強い💪
✅ マトリクス分割が効いた理由
- 1表1責務だから どの分岐をテスト済みか一目で分かる
- レビューで「このノードは100%です！」と宣言できる
- 設計×テストのトレーサビリティが明確
結果的に分岐網羅が爆速で埋まりました✅🚀
運用ルール（鉄則）
1マトリクス ＝ 1ノード（1判断）
複雑なら分割する → 無理に1表にまとめない
実装後のカバレッジレポートと比較して
「分岐網羅」がスムーズに達成できました。
参考にした記事
🔗 https://zenn.dev/unsese/articles/bd6b2ac52afe687ca97d
まとめ
- 設計書ベースで分岐を洗い出すことで抜け漏れ防止
- ノード単位でマトリクスを分割するとシンプルに保てる
- 結果 → 分岐網羅の達成率が向上＆レビューが楽に！
単体試験に苦戦している方の助けになれば嬉しいです😊