データベースアプリケーションのテストデータを用意するとき、どういうデータを用意しますか？
「注文があって出荷してないデータ」「注文があって出荷していて入金がないデータ」という風に業務の流れにそってデータを考えることが多いと思います。
ただ、テストの本を見ても、どうやってテストデータを用意するかということが書かれていることは多くありません。というか市販の本で見たことがありません。
データベースアプリケーションでは、ひとつの処理でまったく分岐がなく上から下にSQLを順番に発行するということが少なくありません。そういうとき、C1とかC2とかの処理カバレッジというのは簡単に100%に近くなってしまい、テストがアプリケーションの状況を網羅しているかどうかという指標にはなりにくくなります。
データベースアプリケーションでは、「すべての処理を行ったかどうか」という処理カバレッジでは充分ではなく「すべてのデータの組み合わせで処理を行ったかどうか」というカバレッジが大切になると思います。つまりデータベースカバレッジ。
このときのデータの作り方を、業務の流れを考えるものではなく、もっと機械的に考えれるようにしたほうがいいんじゃないかと思います。
データベースアプリケーションというのは、多数の状態が同時に存在する中で、興味のある状態を抽出して次の状態に遷移させるという独立した処理を集めたアプリケーションです。そうすると、すべての状態を用意することができれば、処理の流れをテストする必要が低くなり、単独の処理をテストするだけである程度の品質が確保できるようになります。
実際に今回つくった業務アプリで、あらかじめ「データベースカバレッジ」ということを意識したデータを用意しておいたのですが、そうすると
- 処理を組んだときに、すでにその処理を動かせる状況になっている
- 特定の処理を動かすために、処理の流れを追う必要がない
- 処理を軽く流すだけでも不具合が洗い出せる
という風になって、処理の安心感が高くなりました。
データベースアプリケーションにおいては、それぞれの処理に影響のあるデータの組み合わせをすべて用意すること、データベースカバレッジをあげることで単体テストの質をあげることができます。
おそらく、同じことを考えている人は多いと思います。むしろ、日ごろ体系的なテストをしないぼくよりも確立した考えを持っている人も多いのではないかと思います。そういった考えをもっと明文化されていけばいいなぁと思うわけです。
