コードカバレッジはどのくらい「十分」ですか？
私の仕事では、ここでコードカバレッジのプッシュを開始し、それを考えるようになりました...コードカバレッジはどのくらいですか？
コードカバレッジの収益が減少するポイントにいつ到達しますか？十分なカバレッジと十分でない間のスイートスポットは何ですか？作成しているプロジェクトの種類（WPF、WCF、モバイル、ASP.NETなど）によって異なりますか（これらは、私たちが作成しているC＃クラスです）。
少なくとも 70％を目指します。より簡単にテストできるもの（たとえば、関数型データ構造）では、90％を目指しており、ほとんどの個人はできる限り100％に近い値を目指しています。 WPF関連のものや、テストが非常に難しい他のフレームワークでは、カバレッジがはるかに低くなります（かろうじて70％）。
コードカバレッジだけでは不十分な指標だと私は考えています。 coverコードである無益なテストを大量に生成するのは簡単ですが、たとえば、出力を適切にチェックしたり、Edgeケースをテストしたりしないでください。コードをカバーするということは、例外をスローしないことを意味するだけであり、それが正しいというわけではありません。品質テストが必要です。数量はそれほど重要ではありません。
「十分」とは、何も壊さないという確信を持ってコードを変更できるときです。プロジェクトによっては、10％になる場合もあれば、95％になる場合もあります。
100％になることはほとんどありません。ただし、100％のコードカバレッジを得ようとすることは、コードベースから残骸を取り除くための優れた方法になる場合があります。コードカバレッジを増やすには2つの方法があることを忘れないでください-より多くのテストを書くか、コードを取り出すかです。テストが難しいためにコードがカバーされていない場合は、テストを簡単にするために簡略化またはリファクタリングできる可能性が十分にあります。わずらわしくてテストできない場合は、通常、コードの他の何も使用していない可能性が高いです。
コードカバレッジは漸近的に100％に近づきます。その結果、費やした労力に対してゼロに近いリターンを達成し始めると、最後の5％はおそらくそれよりも多くの労力になります。
カバレッジはaメトリックであり、目を離しませんが、最終的な目標ではありません。私はたくさんの高カバレッジコードを見てきました（そして確かに書かれています！）-100％カバレッジ（もちろん、TDD）、まだ：
- バグはまだ出てくる
- デザインはまだ不十分である可能性があります
- あなたは本当に任意のカバレッジターゲットのために射殺することができます-あなたの戦いを選んでください：p
「証言の道」がある entry ここで参照するのが適切だと思う:)
ほとんどのコードの20％が80％の時間実行されます のみです。 call graphと組み合わせて最もテストする必要があるものを特定しない限り、コードカバレッジ分析はあまり役に立ちません。これにより、Edgeケースがどこにある可能性が高いかがわかります。実際のコードの5％未満を構成するこれらのEdgeケースについてのみ100のテストを考え出すことができます。
したがって、クリティカルパスを定義する20％の100％、および残りの少なくとも50％をカバーするようにしてください（コールグラフによると）。これにより、（ほぼ）70％から75％の合計カバレッジが得られますが、状況はさまざまです。
重要なEdgeケースをチェックせずに残しながら、70％以上の合計カバレッジを得ようとする時間を使いすぎないでください。
カバレッジをガイドとして使用して、テストされていない領域を示します。カバーする義務を負うのではなく、コードがカバーされない理由を理解するのが賢明です。不足の理由を記録することは、リスクのバランスをとることができる優れた規律です。
時々理由は望ましいよりも少ないです。時間がなくなりました」が、早期リリースでは問題ない可能性があります。後でカバー範囲を拡大するために戻る領域にフラグを付けることをお勧めします。
100％のステートメントカバレッジが重要でないシステムに適していると見なされる重要なフライトソフトウェアに取り組んでいます。より重要なシステムについては、分岐/決定カバレッジをチェックし、MC/DCを呼び出すテクニックを使用します。
また、オブジェクトコードもカバーしていることを確認する必要があります。
これは、リスク（この場合は非常に高い）と値/コストのバランスです。バグを見逃すリスクに基づいて、情報に基づいた選択が必要です。
より多くのコードカバレッジを可能にするためにランタイムパフォーマンス、セキュリティ、柔軟性、または保守性に影響を与える変更を検討し始めたら、より多くのコードカバレッジの探求を終了する時が来ました。
設計を損なうことなくカバレッジを計算することは不可能であり、他のプロジェクトが92％と高いため、そのポイントが0％のプロジェクトがあります。
コードカバレッジメトリックは、いくつかのテストに失敗した可能性がある場合に指摘する場合にのみ役立ちます。彼らはあなたのテストの品質について何も教えてくれません。
私は@RevBingoの答えが本当に好きです。なぜなら、彼は100％への闘いが未使用のコードをクリーンアップまたは削除する原因になると示唆しているからです。他の回答で私が見たことがないのは、高いカバレッジが必要な場合とそうでない場合です。私はこれを始めるときに刺しました。このようなチャートに詳細を追加することは、すべてのコードに適切な1つのテストカバレッジ番号を見つけるよりも、有用な追求になると思います。
100％
Java.utilコレクションのように、データベースに結合されておらず、HTMLを返さないパブリックAPIの場合、100％のカバレッジは、時間やその他の理由で90-95％に落ち着いても、立派な開始目標だと思います制約。機能の完成後にテストカバレッジを増やすと、他の種類のコードレビューよりも詳細なレベルの精査が必要になります。 APIがまったく人気がある場合、人々はそれを予想外の方法で使用したり、サブクラス化したり、逆シリアル化したりします。あなたは、彼らの最初の経験がバグを発見したり、設計の監視であったりしたくありません！
90％
データ構造を取り込んでデータ構造を返すビジネスインフラストラクチャコードの場合、100％はおそらく最初の目標として適切ですが、このコードが多くの誤用を招くほど一般に公開されていない場合でも、85％は許容範囲でしょうか？
75％
文字列を取り込んで返すコードの場合、単体テストの方がはるかに壊れやすいと思いますが、それでも多くの状況で役立ちます。
50％以下
HTMLは非常に壊れやすいため、HTMLを返す関数のテストを書くのは嫌いです。誰かがCSS、JavaScript、またはHTMLと英語のblob全体を変更した場合、ユーザーのエンドユーザーには意味がありません。多くのビジネスロジックを使用して小さなHTMLを生成する関数を見つけることができる場合、これはテストする価値があります。しかし、逆の状況はテストする価値がないかもしれません。
ほぼ0％
一部のコードでは、「正しい」の定義は「エンドユーザーにとって意味がある」です。自動化された文法チェックや出力のHTML検証など、このコードに対して実行できる従来とは異なるテストがあります。システムの残りの部分が「サインイン」と呼んでいるときに「ログイン」と言うなど、私たちが仕事でよく陥る小さな不一致に対してgrepステートメントを設定しました。この人は厳密には単体テストではありませんが、特定の出力を期待せずに問題を見つけるのに役立つ方法です。
しかし、結局のところ、人間が何に敏感であるかを判断できるのは人間だけです。単体テストはそこで役に立ちません。時々それを正確に判断するのに数人の人間が必要です。
絶対0％
これは悲しいカテゴリーで、私はそれを書く人のようには感じられません。しかし、十分に大きなプロジェクトには、ビジネス上の利益をもたらさずに1週間を費やすことができるうさぎの穴があります。
Hibernateをテストするためにデータを自動的にモックする方法を示していると主張して、本を購入しました。ただし、Hibernate HQLおよびSQLクエリのみをテストしました。多くのHQLとSQLを実行する必要がある場合、実際にはHibernateの利点を活用できていません。 Hibernateインメモリデータベースの形式はありますが、時間をかけてテストで効果的に使用する方法を理解していません。それを実行している場合は、オブジェクトグラフをナビゲートしてHibernateがいくつかのクエリを実行することによってデータを計算するビジネスロジックのテストカバレッジ（50％〜100％）を高くしたいと思います。このコードをテストする私の能力は現在0％に近く、それが問題です。そのため、プロジェクトの他の領域のテストカバレッジを改善し、データベースにアクセスする関数よりも純粋な関数を優先するようにしています。これは、これらの関数のテストを記述しやすいためです。それでも、テストできないもの、またはテストすべきでないものがあります。
スペースクリティカルなソフトウェアには、100％のステートメントカバレッジが必要です。
最初は意味がありません。完全なテストカバレッジがコードが完全にテストされていることを意味するのではなく、実際にアプリケーションをテストせずに100％カバレッジを取得することはそれほど難しいことではないことを誰もが知っています。
それにもかかわらず、100％のカバレッジは下限です。100％のカバレッジはバグのないソフトウェアの証拠ではありませんが、カバレッジが少ない場合、コードは完全にテストされないことは確かであり、これはスペースクリティカルなソフトウェアには受け入れられません。
テストしているアプリケーションの部分に依存すると思います。例えば。ビジネスロジックや複雑なデータ変換を含むコンポーネントの場合、90％（可能な限り高い）のカバレッジを目指します。私は、できるだけ多くのコードをテストするだけで、小さいが危険なバグをしばしば発見しました。このようなバグは、1年後に顧客のサイトで発生させるよりも、テスト中に見つけたいと思います。また、高いコードカバレッジの利点は、テストをそれに応じて調整する必要があるため、作業コードがあまりにも簡単に変更されないことです。
一方、コードカバレッジがあまり適していないコンポーネントがあると思います。たとえば、GUIをテストする場合、イベントを適切なコンポーネントにディスパッチするためにボタンをクリックしたときに実行されるすべてのコードをカバーするテストを記述するのは非常に時間がかかります。この場合、ボタンをクリックしてプログラムの動作を観察する手動テストを実行する従来のアプローチを使用する方がはるかに効果的だと思います（適切なダイアログウィンドウが開いていますか？適切なツールが選択されていますか？ ？）。
テストスイートに十分なカバレッジがあるかどうかを知るための手段としてコードカバレッジを使用することについては、それほど高い意見はありません。
主な理由は、最初にコードを記述し、次にいくつかのテストを記述し、次にコードカバレッジを調べてどこでテストを逃したかを見つけるプロセスがある場合、プロセスを改善する必要があるためです。真のTDDを実行する場合、箱から出してすぐにコードカバレッジが100％あります（確かに、私がテストしていないいくつかの些細な点があります）。ただし、コードカバレッジを調べて何をテストするかを調べると、間違ったテストを作成する可能性があります。
したがって、コードカバレッジから結論付けることができる唯一のことは、それが低すぎると、十分なテストがないということです。しかし、それが高ければ、あなたがすべての正しいテストを持っているという保証はありません。