ユニットテストのコードカバレッジの最小パーセンテージを義務付けるとしたら、おそらくリポジトリへのコミットの要件としてであっても、それは何でしょうか？

どのようにして答えにたどり着いたか説明してください（あなたがしたことのすべてが数字を選んだ場合、私はそれをすべて自分で行うことができたでしょう;）

アルベルト・サボイアによるこの散文は、その質問に正確に答えます（その上で面白い方法で！）：

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

テストカバレッジに関するテスト

ある早朝、プログラマーは偉大なマスターに尋ねました。

「いくつかの単体テストを書く準備ができています。どのコードカバレッジを目指すべきですか？」

偉大なマスターは答えました：

「カバレッジについて心配する必要はありません。良いテストをいくつか書いてください。」

プログラマーは微笑み、お辞儀をして、立ち去りました。

...

その日の後半に、2人目のプログラマーが同じ質問をしました。

偉大な主人は沸騰したお湯の鍋を指さして言った：

「その鍋にいくつの米粒を入れるべきですか？」

困惑しているプログラマーは答えた：

「どうすればあなたに伝えることができますか？それは、あなたが何人の人に食事をする必要があるか、彼らがどれだけお腹が空いているか、他にどんな食べ物を出しているか、どれくらいの量の米を手に入れることができるかなどに依存します。」

「その通り」と偉大な師は言った。

2人目のプログラマーは微笑み、お辞儀をして、立ち去りました。

...

結局、3人目のプログラマーが来て、コードカバレッジについて同じ質問をしました。

「80％、それ以上！」マスターに厳しい声で答え、テーブルの上で拳を叩きました。

3人目のプログラマーは微笑み、お辞儀をして、立ち去りました。

...

この最後の返答の後、若い見習いが大師に近づきました。

「素晴らしいマスター、今日、コードカバレッジに関する同じ質問に3つの異なる答えで答えたのを耳にしました。なぜ？"

偉大な主人は彼の椅子から立ち上がった。

「私と一緒に新鮮なお茶を飲みに来て、それについて話しましょう。」

熱い緑茶を飲んでコップを満たした後、偉大な主人は答え始めました。

「最初のプログラマーは新しく、テストを始めたばかりです。現在、彼にはたくさんのコードがあり、テストはありません。彼には長い道のりがあります。この時点でコードカバレッジに焦点を当てることは、憂鬱でまったく役に立たないでしょう。彼はいくつかのテストを書いて実行することに慣れるだけのほうがいいです。彼は後で報道について心配することができます。」

一方、2番目のプログラマーは、プログラミングとテストの両方の経験が豊富です。ポットに入れる米の粒数を尋ねると、私は彼女が必要なテストの量はいくつかの要因に依存することを理解するのを助けました、そして彼女は私よりもそれらの要因をよく知っています-それは結局彼女のコードです。単一でシンプルな答えはなく、彼女は真実を処理し、それに取り組むのに十分賢いです。」

「なるほど」と若い見習いは言いましたが、「単純な答えが1つもないのなら、なぜ3番目のプログラマーに「80パーセント以上」と答えたのですか？」

偉大な主人は彼の腹ほどに激しく大声で笑いました。彼が緑茶以上のものを飲んだことを証明し、上下に跳ねました。

「3番目のプログラマーは単純な答えだけを望んでいます–単純な答えがなくても…とにかくそれらに従っていません。」

若い弟子とハイイログマの大師は瞑想的な沈黙の中でお茶を飲み終えました。

（すべての機能を100％テストするのではなく）100％のカバレッジが目標である場合、コードカバレッジは誤解を招く指標です。

• すべての行を一度押すと、100％を得ることができます。ただし、これらの行がヒットする特定のシーケンス（論理パス）のテストを失敗する可能性があります。
• 100％を取得することはできませんが、80％/ freqで使用されるすべてのコードパスをテストしました。すべての「throw ExceptionTypeX」または同様の防御的プログラミングガードをテストするテストがあることは、「持っている必要がある」ではなく「持っている必要がある」

したがって、自分自身または開発者を徹底して、コードのすべてのパスをカバーすることを信頼してください。実用的であり、魔法の100％の範囲を追跡しないでください。コードをTDDする場合、ボーナスとして90％以上のカバレッジを取得する必要があります。コードカバレッジを使用して、見逃したコードのチャンクを強調表示します（ただし、TDDの場合は発生しません。テストパスを作成するためにのみコードを記述しているためです。パートナーテストなしではコードは存在できません。）

コードカバレッジは優れていますが、機能カバレッジはさらに優れています。私が書くすべての行をカバーすることを信じていません。しかし、私は提供したいすべての機能の100％テストカバレッジを書くことを信じています（私が自分で持ってきた、会議中に議論されなかった特別な機能についても）。

テストでカバーされていないコードが存在するかどうかは気にしませんが、コードをリファクタリングして別の動作になってしまうかどうかは気になります。したがって、100％の機能範囲が私の唯一のターゲットです。

受け入れられた答えは良いポイントになります-すべてのプロジェクトの標準として意味のある単一の数字はありません。そのような標準を必要としないプロジェクトがあります。私の意見では、受け入れられた答えが不十分であるのは、特定のプロジェクトに対してその決定を行う方法を説明することです。

私はそうすることで写真を撮ります。私はテストエンジニアリングの専門家ではないため、より詳しい情報に基づいた回答をお待ちしています。

コードカバレッジ要件を設定するタイミング

まず、そもそもなぜそのような基準を課したいのでしょうか。一般に、プロセスに経験的な自信を持ちたい場合。「経験的自信」とはどういう意味ですか？まあ、本当の目標の正しさ。ほとんどのソフトウェアでは、すべての入力にわたってこれを知ることができない可能性があるため、コードは十分にテストされていると言っても問題ありません。これはよりわかりやすいですが、それでも主観的な基準です。あなたがそれを満たしたかどうかは、常に議論の余地があります。これらの議論は有用であり、発生するはずですが、不確実性も明らかになります。

コードカバレッジは客観的な測定値です。カバレッジレポートが表示されたら、基準が満たされているかどうかについて曖昧さはありません。それは正しさを証明していますか？まったくそうではありませんが、コードがどれだけ十分にテストされているかと明確な関係があり、それがコードの正確性に対する信頼を高めるための最良の方法です。コードカバレッジは、私たちが気にかけている計り知れない品質の測定可能な近似です。

経験的基準があれば付加価値が得られる特定のケース：

• 利害関係者を満足させるため。多くのプロジェクトでは、ソフトウェアの日常的な開発に関与していない可能性があるソフトウェアの品質に関心のあるさまざまなアクター（マネージャー、テクニカルリードなど）がいます。本当に必要なテスト」は説得力がありません。彼らは完全に信頼するか、継続的な綿密な監視で検証する必要があります（そうするための技術的理解さえ持っていると仮定します）。
• チームの行動を正常化するため。利害関係者はさておき、複数の人がコードとテストを作成しているチームで作業している場合、「十分にテストされた」と見なされるものにはあいまいさの余地があります。どのレベルのテストで十分かについて、同僚全員が同じ考えを持っていますか？おそらく違います。これをどのように調整しますか？すべてに同意できるメトリックを見つけ、それを妥当な近似として受け入れます。これは特に（ただし、排他的ではありませんが）、リードがジュニア開発者を直接監視できないような大規模なチームで役立ちます。信頼のネットワークも重要ですが、客観的な測定がないと、たとえ誰もが誠実に行動していても、グループの行動が一貫しなくなる可能性があります。
• 自分を正直に保つため。あなたがプロジェクトの唯一の開発者であり、唯一の利害関係者である場合でも、ソフトウェアに対して特定の資質を念頭に置いている場合があります。ソフトウェアがどれだけ十分にテストされているか（作業にかかる）に関する継続的な主観的評価を行う代わりに、コードカバレッジを妥当な概算として使用し、マシンに測定させます。

使用するメトリック

コードカバレッジは単一の指標ではありません。カバレッジを測定する方法はいくつかあります。どれを基準に設定するかは、その基準を何に使用して満足するかによって異なります。

標準を設定するためにそれらを使用する場合の例として、2つの一般的なメトリックを使用します。

• ステートメントカバレッジ：テスト中に何パーセントのステートメントが実行されましたか？コードの物理的なカバレッジを理解するのに役立ちます。私が書いたコードのうち、実際にテストしたのはどれくらいですか？
  • この種のカバレッジは、より弱い正当性の議論をサポートしますが、達成も容易です。コードカバレッジを使用して物事が確実にテストされるようにする場合（それ以上のテスト品質の指標としてではない場合）、ステートメントカバレッジでおそらく十分です。
• 分岐カバレッジ：分岐ロジック（例：）がある場合if、両方の分岐が評価されましたか？これにより、コードの論理的なカバレッジをよりよく理解できます。つまり、コードがたどる可能性のあるパスをいくつテストしたでしょうか。
  • この種のカバレッジは、プログラムが包括的な入力セットにわたってテストされていることを示すはるかに優れた指標です。コードカバレッジを正確性の信頼性のための最良の経験的近似として使用している場合は、ブランチカバレッジなどに基づいて標準を設定する必要があります。

他にも多くのメトリックがあります（行カバレッジはステートメントカバレッジに似ていますが、たとえば、複数行ステートメントの数値結果は異なります。条件付きカバレッジとパスカバレッジはブランチカバレッジに似ていますが、可能な置換のより詳細なビューを反映しています。発生する可能性のあるプログラムの実行。）

何パーセント必要か

最後に、元の質問に戻ります。コードカバレッジ標準を設定する場合、その数はどのようになりますか？

うまくいけば、現時点では近似について話していることは明らかであるため、選択する数値は本質的に近似値になります。

人が選ぶかもしれないいくつかの数：

• 100％ 。すべてを確実にテストしたいので、これを選択するかもしれません。これは、テストの品質についての洞察を与えるものではありませんが、何らかの品質のテストがすべてのステートメント（または分岐など）に影響を与えたことを示しています。繰り返しますが、これは信頼度に戻ります。カバレッジが100％未満の場合、あなたはあなたのコードの一部がテストされていないことを知っています。
  • これはばかげていると主張する人もいるかもしれません。実際に重要なコードの部分のみをテストする必要があります。また、コードの中で本当に重要な部分だけを維持する必要があると私は主張します。テストされていないコードも削除することで、コードカバレッジを改善できます。
• 99％（または95％、90年代後半のその他の数値）。100％と同様の信頼度を伝えたい場合に適していますが、時々テストするのが難しいコーナーについて心配しないようにマージンを残してください。コード。
• 80％。私はこの数値を数回使用しているのを見たことがありますが、それがどこで発生したのか完全にはわかりません。私は考えてそれが80-20ルールの奇妙な横領かもしれません。一般的に、ここでの目的は、ほとんどのコードがテストされていることを示すことです。（はい、51％も「ほとんど」ですが、80％はほとんどの人が何を意味するかをより反映しています。）これは、「十分にテスト済み」が優先度の高い中程度の場合に適しています（あなたはしません）価値の低いテストに労力を費やしたいが）、それでも十分な優先順位があり、基準を設定したい場合があります。

実際には80％未満の数値は見たことがなく、設定する場合を想像するのは困難です。これらの基準の役割は、正確性の信頼性を高めることであり、80％未満の数値は特に信頼性を高めるものではありません。（はい、これは主観的ですが、繰り返しになりますが、標準を設定するときに主観的な選択を行い、その後、客観的な測定を使用するという考えです。）

その他の注意事項

上記は、正確さが目標であることを前提としています。コードカバレッジは単なる情報です。他の目標に関連している可能性があります。たとえば、保守性が気になる場合は、おそらく疎結合を気にします。疎結合は、テスト可能性によって示され、コードカバレッジによって（特定の方法で）測定できます。したがって、コードカバレッジ標準は、「保守性」の品質を概算するための経験的基準も提供します。

私のお気に入りのコードカバレッジは100％アスタリスク付きです。アスタリスクが付いているのは、特定の行を「カウントしない」行としてマークできるツールを使用したいためです。「カウント」する行を100％カバーしていれば完了です。

基本的なプロセスは次のとおりです。

1. 私は考えられるすべての機能とエッジケースをテストするためにテストを作成します（通常はドキュメントから作業します）。
2. コードカバレッジツールを実行する
3. カバーされていないラインやパス、重要ではない、または到達できないと考えているライン（防御的なプログラミングのため）を調べます。
4. 不足している行をカバーする新しいテストを作成し、これらのエッジケースが言及されていない場合はドキュメントを改善します。

この方法で、私と共同編集者が新しいコードを追加したり、将来的にテストを変更したりすると、重要なものを見逃したかどうかを示す明るい線が表示されます-カバレッジが100％を下回りました。ただし、さまざまなテストの優先順位に対応する柔軟性も提供します。

共有したいテストカバレッジに関する別の方言があります。

Twitterを介して、700の単体テストでは20％のコードしかカバーしていないという大きなプロジェクトがあります。

スコット・ハンセルマンは知恵の言葉で答えた：

正しい20％ですか？ユーザーが最もヒットしたコードを表すのは20％ですか？さらに50のテストを追加し、2％のみを追加する場合があります。

繰り返しますが、コードカバレッジの回答に関する私のTestivusに戻ります。鍋にどれくらいのご飯を入れるべきですか？場合によります。

ユニットテストが最初から開発を推進してきた、うまく設計されたシステムの場合、85％は非常に低い数値です。テスト可能なように設計された小さなクラスは、それよりも優れたものをカバーするのは難しくありません。

次のようなものでこの質問を却下するのは簡単です：

• カバーされた行はテストされたロジックと等しくないので、パーセンテージを読みすぎてはいけません。

確かに、しかし、コードカバレッジに関して注意すべきいくつかの重要なポイントがあります。私の経験では、正しく使用すると、このメトリックは実際には非常に役立ちます。そうは言っても、すべてのシステムを見たわけではないので、コードカバレッジ分析が真の価値を追加しているのを確認するのが困難なシステムはたくさんあると思います。コードは非常に異なって見える場合があり、使用可能なテストフレームワークの範囲は異なる場合があります。

また、私の推論は主に、非常に短いテストフィードバックループに関係しています。私が開発している製品の場合、最短のフィードバックループは非常に柔軟で、クラステストからプロセス間シグナリングまですべてをカバーしています。成果物サブ製品のテストには通常5分かかり、そのような短いフィードバックループでは、テスト結果（特にここで確認しているコードカバレッジメトリック）を使用して、リポジトリ内のコミットを拒否または受け入れることが実際に可能です。

コードカバレッジメトリックを使用する場合、満たさなければならない固定（任意の）パーセンテージだけを持たないでください。これを行っても、コードカバレッジ分析の本当の利点は得られないと思います。代わりに、次のメトリックを定義します。

• 低水位標（LWM）、テスト中のシステムでこれまでに見られたカバーされていないラインの最小数
• ハイウォータマーク（HWM）、テスト中のシステムでこれまでにない最高のコードカバレッジパーセンテージ

新しいコードを追加できるのは、LWMを超えず、HWMを下回らない場合のみです。言い換えると、コードカバレッジを減らすことはできません。新しいコードをカバーする必要があります。私が言うべきこととすべきではないことに注意してください（以下で説明します）。

しかし、これはあなたがもう使い物にならなくなった古い十分にテストされたゴミをきれいにすることが不可能になるということを意味しませんか？はい、そういうわけで、あなたはこれらのことについて実用的でなければなりません。ルールを破らなければならない状況がありますが、私の典型的な日常の統合では、これらのメトリックは非常に役立ちます。これらは、次の2つの意味を含みます。

• テスト可能なコードが昇格されます。新しいコードを追加するときは、コードをテスト可能にするために努力する必要があります。テストケースでコードをすべてカバーする必要があるためです。通常、テスト可能なコードは良いことです。

• レガシーコードのテストカバレッジは時間とともに増加しています。新しいコードを追加してテストケースでカバーできない場合、LWMルールを回避するために、代わりにレガシーコードをカバーすることを試みることができます。これは時々必要な不正行為により、レガシーコードのカバレッジが時間とともに増加するというプラスの副作用があり、実際にはこれらのルールの厳格な実施が非常に実用的です。

繰り返しになりますが、フィードバックループが長すぎる場合、統合プロセスでこのようなものを設定することは完全に非現実的です。

また、コードカバレッジメトリックの2つの一般的な利点についても触れたいと思います。

• コードカバレッジ分析は、動的なコード分析の一部です（静的な分析（Lintなど）ではありません）。動的コード分析中に検出された問題（purifyファミリ、http： //www-03.ibm.com/software/products/en/rational-purify-familyなどのツールによる）は、初期化されていないメモリの読み取り（UMR）などの問題です。メモリリークなど。これらの問題は、コードが実行されたテストケースでカバーされている場合にのみ検出されます。テストケースでカバーするのが最も難しいコードは、通常、システムの異常なケースですが、システムを正常に失敗させたい場合（つまり、クラッシュではなくエラートレース）、異常なケースをカバーすることに力を入れたい場合があります。動的コード分析でも同様です。ほんの少しの不運で、UMRはセグメンテーションフォールトまたはそれ以上につながる可能性があります。

• 人々は新しいコードのために100％を保つことに誇りを持っています、そして人々は他の実装問題と同様の情熱でテスト問題を議論します。この関数をよりテスト可能な方法でどのように書くことができますか？この異常なケースなどをどのようにカバーしようとしますか？

そして、完全性のために、ネガ。

• 多くの開発者が関与する大規模なプロジェクトでは、誰もがテストの天才になるとは限りません。この質問に対する他の多くの回答で述べられているように、一部の人々は、コードカバレッジメトリックをコードがテストされたことの証明として使用する傾向があり、これは真実とはかけ離れています。これは1つの指標であり、適切に使用すれば優れたメリットが得られますが、誤って使用すると、実際には悪いテストにつながる可能性があります。上記の非常に貴重な副作用を除いて、カバーされた行は、テスト対象のシステムが一部の入力データについてその行に到達でき、ハングまたはクラッシュすることなく実行できることを示しています。

これが完璧な世界であれば、コードの100％は単体テストでカバーされます。しかし、これは完璧な世界ではないので、時間の問題です。そのため、特定の割合に重点を置くのではなく、重要な領域に重点を置くことをお勧めします。コードが適切に記述されている場合（または少なくとも妥当な複製）、APIが他のコードに公開される重要なポイントがいくつかあるはずです。

これらのAPIにテストを集中してください。APIが1）十分に文書化されており、2）文書に一致するテストケースが記述されていることを確認してください。期待される結果がドキュメントと一致しない場合は、コード、ドキュメント、またはテストケースにバグがあります。これらはすべて精査に適しています。

幸運を！

多くのショップはテストを重視していません。そのため、少なくともゼロを超えている場合は、価値があるという評価があります。そのため、多くの場合ゼロでないことは間違いなく、ゼロでないことは悪くありません。

.Netの世界では、人々はしばしば80％を妥当であるとしています。しかし、彼らはこれをソリューションレベルで言います。プロジェクトレベルで測定することを好みます。Seleniumなどの手動テストがある場合、UIプロジェクトでは30％で十分ですが、データレイヤープロジェクトでは20％でも問題ないかもしれませんが、ビジネスでは95％以上を達成できる可能性があります。完全に必要でない場合は、ルール層。したがって、全体のカバレッジはたとえば60％になる可能性がありますが、重要なビジネスロジックははるかに高くなる可能性があります。

私もこれを聞いたことがあります。100％を目指すと80％ヒットします。80％を目指すと40％ヒットします。

結論：80:20のルールを適用し、アプリのバグ数を参考にしてください。

コードカバレッジは、もう1つの指標です。それ自体、非常に誤解を招く可能性があります（www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overratedを参照）。したがって、目標は100％のコードカバレッジを達成することではなく、アプリケーションのすべての関連シナリオを確実にテストすることです。

85％は、チェックイン基準の出発点として適しています。

テストするサブシステム/コンポーネントの重要度に応じて、私はおそらく出荷基準にさまざまなより高い基準を選択しました。

私はcoberturaを使用していますが、パーセンテージが何であれ、cobertura-checkタスクの値を最新に保つことをお勧めします。少なくとも、totallinerateとtotalbranchrateを現在のカバレッジのすぐ下まで上げ続けますが、これらの値を下げないでください。また、Antビルドエラープロパティをこのタスクに関連付けます。カバレッジが不足しているためにビルドが失敗した場合、誰かが追加したコードはわかっていますが、テストしていません。例：

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

コードの単体テストが十分ではなく、次に何をテストするかわからない場合は、カバレッジを使用して、次に何をテストするかを決定します。

単体テストでカバレッジを増やした場合-この単体テストは何か価値があることがわかります。

これは、カバーされていない、50％カバーされている、または97％カバーされているコードに当てはまります。

私はBDDを実行することを好みます。BDDは、自動受け入れテスト、おそらく他の統合テスト、および単体テストの組み合わせを使用します。私にとっての問題は、自動テストスイート全体の対象範囲をどのようにするかです。

それはさておき、答えは、方法論、言語、テスト、カバレッジツールによって異なります。RubyまたはPythonでTDDを実行する場合、100％のカバレッジを維持することは難しくありません。そうすることには価値があります。100％のカバレッジを管理する方が、90％程度のカバレッジよりはるかに簡単です。つまり、カバレッジギャップが表示された場合（およびTDDを実行する場合、カバレッジギャップがまれであり、通常は時間に見合う価値がある場合）は、まだ到達していないカバレッジギャップのリストを管理してカバレッジを見逃すよりもはるかに簡単です。カバーされていないコードの継続的なバックグラウンドによる回帰。

答えは、プロジェクトの履歴にも依存します。上記は、最初からそのように管理されたプロジェクトでのみ実用的であることがわかりました。大規模なレガシープロジェクトのカバレッジを大幅に改善したので、その価値はありますが、カバレッジギャップをすべて埋めるのは現実的ではありません。これは、テストされていない古いコードが正しく理解できていないためです。早く。

ユニットテストをかなりの時間行っている場合、95％以上に達しない理由はありません。ただし、最低でも、テストに不慣れな場合でも、常に80％で作業してきました。

この数には、プロジェクトで記述されたコード（フレームワーク、プラグインなどを除く）のみを含め、外部コードへの呼び出しで記述されたコードのみで構成される特定のクラスを除外することもできます。この種の呼び出しは、モック/スタブする必要があります。

一般的に言って、私が読んだいくつかの優れたエンジニアリングのベストプラクティスペーパーから、単体テストの新しいコードの80％が最良のリターンを生み出すポイントです。そのCC％を超えると、労力の量に応じて欠陥が少なくなります。これは、多くの主要企業で使用されているベストプラクティスです。

残念ながら、これらの結果の大部分は企業の内部のものであるため、私が指摘できる公開文献はありません。

コードカバレッジは素晴らしいですが、それから得られる利点がそれを達成するためのコスト/努力を上回っている限りだけです。

私たちはしばらくの間、標準の80％に取り組んでいますが、これを断念してテストに集中するように決定しました。複雑なビジネスロジックなどに集中

この決定は、コードカバレッジの追跡と既存の単体テストの維持に費やす時間が増えたために行われました。コードカバレッジから得られる利益は、それを達成するために費やさなければならない努力よりも少ないと見なされるようになったと感じました。

短い答え：60-80％

長い答え：それはプロジェクトの性質に完全に依存すると思います。私は通常、すべての実用的な部分を単体テストすることによってプロジェクトを開始します。プロジェクトの最初の「リリース」までに、実行しているプログラミングのタイプに基づいたかなり良い基本パーセンテージが得られるはずです。その時点で、最小限のコードカバレッジを「強制」することができます。

Crap4jをチェックしてください。これは、単純なコードカバレッジよりも少し洗練されたアプローチです。コードカバレッジ測定と複雑さ測定を組み合わせて、現在テストされていない複雑なコードを示します。

この難問に対する私の答えは、テストできるコードの100％のラインカバレッジと、テストできないコードの0％のラインカバレッジを持つことです。

私の現在のPythonの実践では、.pyモジュールをapp1 /とapp2 /の2つのフォルダーに分割し、単体テストの実行時にこれら2つのフォルダーのカバレッジを計算して視覚的に確認します（私は app1のカバレッジが100％であることいつかこれを自動化するます）。 app2のカバレッジは0％です。

これらの数値が標準と異なることが判明した場合は、カバレッジが標準に準拠するように調査し、コードの設計を変更します。

これは、ライブラリコードの100％のラインカバレッジを達成することをお勧めできることを意味します。

また、app2 /を時々レビューして、そこでコードをテストできるかどうかを確認し、できればapp1 /に移動できる

総カバレッジはプロジェクトのサイズによって大きく異なるため、あまり心配していませんが、通常は70％から90％を超えています。

Pythonを使用すると、カバレッジを測定しながらアプリを自動的に実行し、煙のテストと単体テストの数値を組み合わせると100％の集計が得られる煙のテストを考案できるはずです。

カバレッジを別の観点から見る：明確な制御フローを備えた適切に記述されたコードは、カバーするのが最も簡単で、読みやすく、通常はバグの少ないコードです。明確さとカバー可能性を念頭に置いてコードを記述し、コードと並行して単体テストを記述することで、IMHOで最良の結果を得ることができます。

私の意見では、答えは「どれだけの時間があるかによる」というものです。私は100％を達成しようとしますが、私が持っている時間でそれを得なければ、大騒ぎはしません。

単体テストを作成するときは、製品コードの開発時に着用する帽子とは異なる帽子を着用します。テストしたコードが何を主張しているのか、それを壊す可能性のある状況は何かについて考えています。

私は通常、次の基準または規則に従います。

1. ユニットテストは私のコードの期待される振る舞いが何であるかについてのドキュメントの形式であるべきだということです。特定の入力が与えられた場合に予想される出力と、クライアントがキャッチしたい例外をスローする可能性がある（コードのユーザーが知っておくべきことは何か）

2. 単体テストは、私がまだ考えていない可能性のある条件を発見するのに役立つはずです。（コードを安定して堅牢にする方法は？）

これらの2つのルールが100％のカバレッジを生成しない場合は、そうなります。しかし、時間があれば、カバーされていないブロックと行を分析し、ユニットテストのないテストケースがまだあるかどうか、またはコードをリファクタリングして不要なコードを排除する必要があるかどうかを判断します。

それはあなたのアプリケーションに大きく依存します。たとえば、一部のアプリケーションは、主にユニットテストできないGUIコードで構成されています。

そのような白黒ルールはあり得ないと思います。
特に重要な詳細に注意して、コードをレビューする必要があります。
ただし、テストされていない場合はバグがあります。

コードの重要度に応じて、75％〜85％の範囲が良い経験則です。配送コードは、家庭用ユーティリティなどよりも徹底的にテストする必要があります。

これは、アプリケーション開発ライフサイクルのどの段階にいるかに依存する必要があります。

開発期間が長く、すでに多くのコードを実装していて、コードカバレッジについて考える必要があることに気付いた場合は、現在のカバレッジ（存在する場合）を確認し、そのベースラインを使用して、各スプリント（またはスプリント期間中の平均上昇）のマイルストーンを設定します。つまり、エンドユーザーに価値を提供し続けながらコードの負債を引き受けます（少なくとも、私の経験では、テストを増やしてもエンドユーザーは少し気にしないでください）新しい機能が表示されない場合の対応範囲）。

ドメインによっては、95％で撮影することは不合理ではありませんが、平均して85％から90％のケースを検討することになります。

正しいコードカバレッジの最も良い症状は、単体テストで修正できる具体的な問題の量が、作成した単体テストコードのサイズに合理的に対応していることだと思います。

最も重要なことは、カバレッジトレンドが時間の経過とともにどうなるかを知り、トレンドの変化の理由を理解することだと思います。トレンドの変化を良いものと悪いもののどちらで見るかは、理由の分析に依存します。

数日前までは80％以上をターゲットとしていましたが、生成コードをたくさん使用した後は、％ageは気にせず、必要なカバレッジについてレビュー担当者に電話をかけます。

Testivusの投稿から、答えのコンテキストは2番目のプログラマーである必要があると思います。実用的な観点からこれを述べたとしても、努力するためのパラメーター/目標が必要です。これは、私たちがアーキテクチャ、機能（ユーザーストーリー）を備えたコードを分析することによってアジャイルプロセスで「テスト」でき、それから数を考え出すことができると思います。テレコム分野での私の経験に基づくと、60％はチェックするのに良い値だと思います。