データベースカバレッジという考え方
http://d.hatena.ne.jp/nowokay/20050822#1124672022
データベースアプリケーションでは、ひとつの処理でまったく分岐がなく上から下にSQLを順番に発行するということが少なくありません。そういうとき、C1とかC2とかの処理カバレッジというのは簡単に100%に近くなってしまい、テストがアプリケーションの状況を網羅しているかどうかという指標にはなりにくくなります。
データベースアプリケーションでは、「すべての処理を行ったかどうか」という処理カバレッジでは充分ではなく「すべてのデータの組み合わせで処理を行ったかどうか」というカバレッジが大切になると思います。つまりデータベースカバレッジ。
これ、重要ですよね〜。
私は、単体テストの時にはWhere句の条件一つ一つについて境界値のテストができるようにデータを作っています。もろコードから起こしているので、テストの資産価値は低いですが。でも、データってそんなに変わることはないし、あまり不便に感じたことはないです。あっ、これは変更しないことにこだわるプロセスでしか開発してないからか。
テーブル設計（データモデリング？）をする際に、Where句に含まれそうな項目ってだいたいわかるように思います。他の人がテーブル設計をした場合でも、意図が伝わりやすい。テーブル構造に着目すると、
- 主キー
- 外部キー
- 区分
- 開始日・終了日
- 無効フラグ
