質問: 単体テスト、結合テストについて質問です。 私はこれらのテストについて以下のように考えております。 * 単体テストについて 単体テストはカバレッジが100%になることを確認するものと考えており、先にテストソースを書いてから仕様書を書いています。 * 結合テストについて 結合テストは予めテストケースを考えてからブラックボックステストを行い、処理が想定通りに行われることを確認するものと考えています。 * お伺いしたいこと カバレッジを100%にするための単体テストの意味が分からなくなってきており、ソース記述と仕様書作成の順番も逆のような気がします。少し理想論すぎるとも思うのですが、本来は仕様書を先に書き、それを元にテストを記述して実行した結果カバレッジを100%にするものなのでしょうか。 また、結合テストケースは作ろうと思えば際限なく作れそうに思え、その線引きに悩んでいます。例えば5つの定義が記述されている定義ファイルを読み込む機能のテストをする場合、各定義キーの値が記述されているかいないかの組み合わせだけでも2の5乗で32通りあると思います。結合テストケースの線引きは製作物の重要度等を考慮してテスト作成者がテストケースを取捨選択するものと捉えてよいのでしょうか。 それ以外にも回答者様のテスト方針等がありましたら聞かせていただけると幸いです。よろしくお願い致します。
回答: テストに対する考え方は色々あるので、アンケート的な質問と思いました。 そこで、私の考え方を書いてみます。(必ずしも「正しい」とは限りませんので、ご用心。) テストは、テスト対象のプログラムが仕様を満たしていることを検証するために行うものです。 そのためには、まずテスト対象プログラムの「仕様」が明確になっていることが必要です。 「仕様」があれば、正しい姿が明確なのでその通り動作していることを検証する「テスト仕様」を設計できます。この時、全てのケースをテストすることは現実問題不可能ですので、省略しても良い部分は省きます。 さて、省いて良いと思ったけど人間の判断ですから、重要なコードのテストが漏れたり、重要な条件分岐が適切に分岐していることのテストが漏れたりすることがよくあります。それをできるだけ防ぐために、カバレッジを計測し、重要なコードや分岐について必要なテストができていることをチェックし、漏れが見つかったらテスト仕様へフィードバックするとよりテスト仕様にできます。 しかし、この方法でカバレッジを100%にすることはかなり困難です。 一般にはスタブを入れるなどして、条件分岐させると思います。しかし、カバレッジ100%を目指した場合、if文の中身を見て条件分岐するようにスタブを作りがちになるので、条件分岐のバグを検出できるのか、強い疑問を感じます。 テスト・リソースには限りがあるので、カバレッジ100%を目指すより、テスト仕様が「仕様」を本当に検証できているのか、思わぬ使い方が存在しないか、レビューなどした方がテスト効率が良いと、個人的には考えています。