テストケース設計：テストケース量とリスクのバランス

システムのどの場面においてもテストを作る際は、テストケースを先に作る。

その際「テストケースは十分なのか」で不安になって作りすぎることが多いかもしれない。

その際にはこのことを思い出してほしい。

テストケース量は、エラー発生時の悪影響の大きさで判断する

よくある判断事例（ただし、完全な正解などない）

ドメインモデルではテストケース量を増やす

ドメインモデルはシステム・ビジネスの中心であり、ここに不具合が発生するとサービス全体に影響が波及してしまう。

なので、中心であるこの部分は、慎重にテストケースを増やしておいた方が良いと私は考える

永続化に関わるロジック周りはテストケース量を増やす

1度永続化すると、それを戻すのはコストが大きくなる。

例えば、間違ったロジックでデータを整形して保存しており、後になって気付いても、それまでの変更を戻すのは面倒くさい。

そういう意味で、永続化に関わる部分のロジックは慎重になっていた方がいい。

ユーザーからの読み取り要求に関わるロジックは、基本的にはテストケース量を抑えても良い

書き込みと違って、読み取り部分は間違っていたとしても、そこまで大きな影響は出ない。

間違っていたと気付いたらすぐに修正も可能である。なので、リスクはそこまで大きくない。

読み取り用の関数だとしても、依存される数が多いとかなら、テストケース量を増やして影響を少なくしておいた方が良い

金融・ロケットなどのドメインでのテストケース量は全体的に増えそう

「信頼性」が重要視される界隈のシステムっていうのは、テストケースも全体的に増える。

基本は慎重に倒しておいて、本当に楽にしていいところだけそうするというやり方になりそう。

新規事業や個人情報を扱わないシステムなどはテストケース量は楽にして良さそう

金融などとは反対で、もはやバグがあったらテストケース追加していくくらいの心持ちでいい。

ユーザーに多大な影響はそこまで出ないので。

table: ドメインによる戦略の使い分けの参考

ドメイン 戦略 理由

--- ---- ----

金融・医療・航空 最初から厚く 失敗の許容度がゼロに近い

新規事業・実験的プロダクト 薄く始めて段階的に スピード重視、失敗から学ぶ

一般的なWebサービス 中間的アプローチ リスク領域は厚く、それ以外は段階的

ただ、テスト・テストケースを作る人たちは、こういう判断基準を自分の中に持っておくべきである。指針が無ければ修正することすらできないから。