質問: アーキテクトとしてアプリの方針などを考える仕事をしています。 単体試験の工程にて、jUnitをやることになると必ず問題になるのがカバレッジ計測率のお話。 多くの本やサイトではカバレッジ100%までやる必要がないと記載がありますし、個人的にもやりたくないのですが、提案の段階でカバレッジを100%を目指さない論理を持っていません。 100%までやらないと全てのパターンを網羅してると言えないのでテストとして不十分だ。と言われてしまうと反論ができません。 以下をご教示いただきたいです。 * カバレッジを100%にしなくてもいい理由 * お客さんを納得させるための論理・根拠
回答: 僕は受注開発してないので後者はわかりませんが、前者について。(私見です) 〇カバレッジを100%にしなくていい理由 機械的にC0/C1/C2のテストしようとしたらテストケースってコードで増減しますよね。 分岐を上手に減らせばテストケースは減ります。 逆に、下手なコーディングするとカバレッジ100%を達成するのに必要なコーディング量は倍々ゲームで増えていきます。 ここで、本来のTDDで言われるような単体テストの目的を考えてみてください。 最初に単体テストが提唱されているのは、目的に叶ったメソッドデザインを作成する、そしてその目的が達成できているかどうかをチェックすることです。 つまり、「外側から見た構造」をテストしていくんですよね。 機能設計が先か、実装が先かって話で、内部コードのカバーはデザイン時に決定されません。 ってことは、利用目的から内部コードのカバレッジ100%を目指すことはできません。 =カバーコスト(内部カバレッジ100%)は顧客要望から導き出すことができないということです。 事前にボリュームが分からないのに、合意は成立しません。 カバーコストは上手な人が作れば減るでしょうし、下手な人が作れば増えるでしょう。 要件がおかしいとか、経験的なボイラーテンプレートによるメトリクスの肥大化も考えられます。 一方で、要求仕様自体は当初から(拡張・変更こそあれ)一定のはずです。 カバレッジからスタートすると、要件とのミスマッチが発生してしまいます。 カバレッジ100%目的のユニットテストは設計とは逆の、パッチングに近いテストコードになってしまうでしょう。 インテグレーションテストは基本的にシナリオベースですし、単体テストもそうではないか、と考えています。