回答:
少なくとも 70％を目指しています。より簡単にテストできるもの（機能データ構造など）については、90％を目指しており、ほとんどの個人は可能な限り100％に近いことを目指しています。テストが非常に困難なWPF関連のものやその他のフレームワークでは、カバレッジがはるかに低くなります（ほとんど70％）。
私は、コードカバレッジだけでは不十分なメトリックであると考えています。コードをカバーする無数のテストを簡単に作成できますが、出力を適切にチェックしたり、エッジケースをテストしたりしないでください。コードをカバーするということは、それが正しいことではなく、例外をスローしないことを意味します。品質テストが必要です。量はそれほど重要ではありません。
「十分な」とは、何も壊していないという自信を持ってコードを変更できる場合です。プロジェクトによっては、10％になることもあれば、95％になることもあります。
100％ほどになることはほとんどありません。ただし、100％のコードカバレッジを取得しようとすると、コードベースから不要なものを取り除くのに最適な場合があります。コードカバレッジを増やすには2つの方法があることを忘れないでください。テストをさらに書くか、コードを削除します。テストが難しいためにコードがカバーされていない場合は、テストを簡単にするために単純化またはリファクタリングできる可能性が高くなります。テストするのが面倒な場合は、通常、コード内で他に何も使用していない可能性が高くなります。
ほとんどのコードの20％だけが80％の時間実行されます。コードカバレッジ分析は、コールグラフと組み合わせて最も多くのテストが必要なものを判断しない限り、あまり役に立ちません。これは、エッジケースがどこにある可能性があるかを示しています。実際のコードの5％未満を構成するこれらのエッジケースだけのために、100のテストを考え出すことができます。
そのため、クリティカルパスを定義する20％の100％、および残りの少なくとも50％（コールグラフによる）をカバーするようにしてください。これにより、全体のカバー率は（ほぼ）70％から75％になりますが、さまざまです。
チェックせずに重大なエッジケースを残しながら、70％を超えるカバレッジを取得しようとして時間を無駄にしないでください。
カバレッジをガイドとして使用して、テストされていないエリアを示します。カバレッジを委任するのではなく、カバーされないコードの理由を理解する方が賢明です。不足の理由を記録することは、リスクのバランスを取ることができる良い規律です。
理由が「時間切れ」などの望ましいものではない場合もありますが、早期のリリースでは問題ない場合があります。エリアにフラグを付けて、後でカバレッジを向上させるために戻ることをお勧めします。
私は重要なフライトソフトウェアに取り組んでおり、100％のステートメントカバレッジが重要でないシステムに適していると考えられています。より重要なシステムについては、ブランチ/デシジョンカバレッジをチェックし、MC / DCと呼ばれるテクニックを使用します。
また、オブジェクトコードもカバーしていることを確認する必要があります。
これは、私たちの場合、価値/コストに対するリスクのバランスです。バグを見逃すリスクに基づいて、情報に基づいた選択が必要です。
@RevBingoの答えが本当に好きです。彼は、100％への闘いが未使用のコードをクリーンアップまたは削除する可能性があることを示唆しているからです。他の回答で私が見たことがないのは、いつ高い報道が必要か、そうでないかという感覚です。これを開始する際に刺しました。このようなチャートに詳細を追加することは、すべてのコードに適したテストカバレッジ番号を1つ見つけるよりも、より有益な追求になると思います。
java.utilコレクションのようなパブリックAPIの場合、データベースに結合されておらず、HTMLを返さないため、時間やその他の理由で90〜95％に落ち着いても、100％のカバレッジが最初の目標であると考えています。制約。機能が完了した後にテストカバレッジを増やすと、他の種類のコードレビューよりも詳細なレベルの精査が強制されます。APIがまったく人気がある場合、人々はあなたが期待できない方法でそれを使用し、サブクラス化し、デシリアライズします。彼らの最初の経験がバグを発見したり、設計を監督したりするのは望ましくありません！
データ構造を取り込んでデータ構造を返すビジネスインフラストラクチャコードの場合、100％がまだ出発点として適切な可能性がありますが、このコードが多くの誤用を招くほど公開されていない場合、85％がまだ受け入れられるでしょうか？
文字列を取り込んで返すコードの場合、単体テストははるかに脆弱であると考えますが、多くの状況では依然として有用です。
HTMLは非常に壊れやすいので、HTMLを返す関数のテストを書くのは嫌です。誰かがCSS、JavaScript、または返されるHTMLと英語のblob全体を変更すると、人間のエンドユーザーにとって意味がありません。多くのビジネスロジックを使用して小さなHTMLを生成する関数を見つけることができる場合、これはテストする価値があります。しかし、逆の状況はまったくテストする価値がないかもしれません。
一部のコードでは、「正しい」の定義は「エンドユーザーにとって意味があります」です。自動化された文法チェックや出力のHTML検証など、このコードに対して実行できる非伝統的なテストがあります。私は、システムの他の部分が「ログイン」と呼ぶときに「ログイン」と言うような、職場でよく捕らえられる小さな矛盾に対してもgrepステートメントを設定しました。この人は厳密に単体テストではありませんが、特定の出力を期待せずに問題をキャッチするのに役立つ方法です。
しかし最終的には、人間だけが賢明なことを判断できます。単体テストはあなたを助けることはできません。時にはそれを正確に判断するのに数人の人間が必要です。
これは悲しいカテゴリーであり、私はそれを書く人が少ないと感じています。しかし、十分に大きなプロジェクトでは、ビジネス上の利益をもたらさずに数週間の時間を費やすことができるウサギの穴があります。
Hibernateをテストするためにデータを自動的にモックする方法を示すと主張したため、私は本を買いました。ただし、Hibernate HQLおよびSQLクエリのみをテストしました。多くのHQLとSQLを実行する必要がある場合、実際にはHibernateの利点を活用できていません。Hibernateのメモリ内データベースの形式がありますが、テストで効果的に使用する方法を見つけるための時間を費やしていません。それを実行している場合、オブジェクトグラフをナビゲートしてHibernateにクエリを実行させることにより、物事を計算するビジネスロジックのテストカバレッジを高く（50％-100％）したいと思います。このコードをテストする私の能力は、現在0％近くにあり、それは問題です。そのため、プロジェクトの他の領域のテストカバレッジを改善し、データベースにアクセスする機能よりも純粋な機能を優先するようにします。これは、これらの機能のテストを作成する方が簡単だからです。それでも、
テストするアプリケーションの部分に依存すると思います。たとえば、ビジネスロジックや、複雑なデータ変換を伴うコンポーネントの場合、90％（できるだけ高い）カバレッジを目指します。できるだけ多くのコードをテストするだけで、小さいながらも危険なバグを発見することがよくあります。1年後に顧客のサイトで発生させるよりも、テスト中にそのようなバグを見つけたいと思います。また、高いコードカバレッジの利点は、テストをそれに応じて適応させる必要があるため、作業中のコードを簡単に変更できないようにすることです。
一方、コードカバレッジがあまり適していないコンポーネントがあると思います。たとえば、GUIをテストする場合、適切なコンポーネントにイベントをディスパッチするためにボタンをクリックすると実行されるすべてのコードをカバーするテストを記述するのは非常に時間がかかります。この場合、ボタンをクリックしてプログラムの動作を観察する手動テストを実行する従来のアプローチを使用する方がはるかに効果的だと思います（正しいダイアログウィンドウが開きますか？正しいツールが選択されますか？ ？）。
テストスイートに十分なカバレッジがあるかどうかを知るための手段として、コードカバレッジを使用することについて、それほど高い意見はありません。
その主な理由は、最初にコードを作成し、次にテストを行い、次にコードカバレッジを見て、テストを逃した場所を発見するプロセスがある場合、それが改善が必要なプロセスであるためです。真のTDDを行うと、すぐに100％のコードカバレッジが得られます（確かに、テストしていない些細なこともあります）。ただし、コードカバレッジを調べてテスト対象を見つけると、間違ったテストを作成する可能性があります。
したがって、コードカバレッジから結論付けることができるのは、低すぎると十分なテストがないことです。しかし、それが高い場合、すべての適切なテストがあるという保証はありません。