単体テストのコード カバレッジに関するガイドラインをまとめている最中で、実際に意味のある数値を指定したいと考えています。費用対効果の分析を考慮せずに、インターネット全体で見られる 100% のマントラを繰り返すのは簡単です。
実際の中規模/大規模プロジェクトのコード カバレッジを実際に報告した人からのコメントを求めます。何パーセント見ましたか？多すぎるとはどのくらいですか？開発者が高品質のコードを作成するのに役立つバランス (数値) が本当に必要です。65% のカバレッジは期待するには低すぎますか? 80%って高すぎない？
コード カバレッジと循環的複雑度を組み合わせる場合は、CRAP メトリックを使用できます。
artima.comから:
個々の方法の解釈:
Bob Evans と私は (私たちのコードと多くのオープン ソース プロジェクトを使用して) 多くの例を見て、多くの意見に耳を傾けてきました。多くの議論の末、私たちは最初に 30 の CRAP スコアをくだらないことのしきい値として使用することにしました。以下は、メソッドの複雑さに基づいて、CRAP しきい値を下回るために必要なテスト カバレッジの量を示す表です。
メソッドの循環的複雑度 必要なカバレッジの割合
CRAPpy しきい値未満
------------------------------ -------------------------------- ------------
0 – 5 0%
10 42%
15 57%
20 71%
25 80%
30 100%
31+ メソッドを保持するテストはありません
この複合体はCRAP領域外です。
コード カバレッジの量だけでは、「高品質のコード」を保証することはできません。
コメントから...
単純なメソッドにカバレッジのパスを与えるのは、明らかに緩すぎます。これを既存のコードに実装すると、これらの醜いメソッドをリファクタリングするにつれてコード カバレッジが向上することがわかります (コード カバレッジは向上するはずです。そうしないと、危険なリファクタリングを行うことになります)。
0 ～ 5 は本質的に簡単に達成できる成果であり、ROI はそれほど大きくありません。そうは言っても、これらの方法はテストが非常に簡単なことが多いため、TDD の学習に最適です。
個人的には 80% のカバー率を目指しますが、もちろんこれは相対的なものです... 私自身もまだこれを達成していません。
現在、ユーティリティ クラスのカバー率は非常に高く (99%)、これは良いことです。そこにあるバグは、アプリケーション全体を追跡するからです。
ほとんどの GUI のカバレッジは平凡です。それらのテストを作成するのは難しく、時間もかかるためです。そのため、多くの場合、単体テストで GUI を開き、エラーがなければ自動的に閉じます。
唯一の正解は、できる限りテストすることです。明らかに、これはすべてのエンジニアリングプロジェクトにわたる公理です。
それを超えて、それはすべて主観的であり、目前のプロジェクトに大きく依存しています。たとえば、ロッキードが出した飛行制御システムは80％以上テストしたほうがよいですが、XMLビューアへのGUIフロントエンドには80％で十分かもしれません。
通常、チームでテストを実行するコストを分析します。理論の世界では、質問の結果として工数がかかるのが通例です。どのくらいのテストを行うことができますか？
この後、モジュールを調べて、コードのどの部分が最も多くの時間を費やしているかを判断します。重要な各モジュールは1回カバーする必要があります。これ以降、特定のモジュールが実行される時間と比較して、適切な数のテストを実行します。したがって、最終的には、「X％」の厳密な数値がカバーされることはありません。
ジョン・ムーサはこの主題について本当に興味深い本を持っています。
私が参加しているプログラム (~500k SLOC) では、100% を使用しています。これは、テストの次の段階に進むためのプログラム要件です。その背後にある理由は次のとおりです。
プログラムは、いくつかの安全上の重要な状況で使用され、公称条件から外れてテストされないようにしたくない場合
100% を達成していない場合は、必要のないコードを作成してお金を浪費しているか、公称パスを完全にテストしていないかのいずれかです。＃1を参照してください。
単体テストのシナリオでは、使用している実際のプログラム コード カバレッジ メトリックに関係なく、自然に 100% に近づくはずです。誰かが名目上のシナリオに基づいて 95% に達している場合、100% を要求することは面倒ではありません (また、100% に達していない理由を尋ねる必要があります。#2 を参照してください)。
あなたの走行距離は確かに異なります。ミッション / セーフティ クリティカルなアプリケーションに取り組んでいない場合は、おそらくコード カバレッジについてそれほど心配する必要はありません。必要ですか？
[編集]
以下で受け取ったコメントに基づいて、明確にする必要があります。プログラム ガイドラインは、単体テストの 100% のコード カバレッジです。技術的な理由でコードのブランチに到達できない場合 (保護された既定のコンストラクターが呼び出されないなど)、その開発プロセスの要件を放棄することができます。承認は通常、組織の外部の独立した部分から付与されます (go go SQA) ）。
統合/システム テストから、要件カバレッジを見始めると、コード カバレッジは意味のないものになります。それはまったく別の糸の玉です。
元の質問は、現実世界の状況を探していました: すべての現実世界の状況が (ほとんど?) 単体テスト レベルで 100% のコード カバレッジを保証するわけではないことに同意しますが、確かにそうするケースとそうするプログラムがあります。また、一部の開発者は、必要のないコードを作成する習慣があり、テストされないままになります。これはメンテナンスの悪夢となります。後の開発者は、決して使用されることを意図していない (または誰かが「良い」アイデアだと思ったために含まれていた) メソッドを呼び出すためです。100% のカバレッジを狙うと、「なぜこれを書いたのか」という質問に答える必要があります。
コードカバレッジが多すぎるとは思えません。アプリケーションで「通常のビジネス コース」を実行するコードを特定し、それを完全にカバーする必要があると思います。通常のビジネスの過程にない残りのコードについては、最も重要なものを最初に実行することから始めてください。それほど重要ではない異常なビジネスは、適切なコード カバレッジを得るための利益が低くなります。
それは本当に依存します。私は 0% になるソフトウェアをたくさん知っています。% が 1 桁のソフトウェアがたくさんあります。主な問題は、何が本当に必要であり、財政的に望んでいるのかということです。