単体テストの妥当なコード カバレッジ % はどれくらいですか (そしてその理由も)。[閉まっている]
https://stackoverflow.com/questions/90002
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
おそらくリポジトリにコミットするための要件として、単体テストのコード カバレッジの最小パーセンテージを義務付けるとしたら、それは何になるでしょうか?
どのようにして答えにたどり着いたのか説明してください (数字を選ぶだけなら、私一人ですべてできたのに ;)
解決
アルベルト・サヴォイアのこの散文は、まさにその質問に答えています（とても面白い形で！）。
http://www.artima.com/forums/ flat.jsp?forum=106&thread=204677
テスト範囲に関する証言
ある朝、プログラマーが偉大なマスターに尋ねました：
「いくつかの単体テストを作成する準備ができました。どのコードカバレッジを目指すべきですか？」
偉大なマスターはこう答えました。
「カバレッジのことは気にしないで、良いテストをいくつか書いてください。」
プログラマーは微笑んで、お辞儀をし、去りました。
...
その日遅く、2番目のプログラマーが同じ質問をしました。
偉大なマスターは沸騰したお湯の鍋を指して言った：
「その鍋にお米を何粒入れればいいですか？」
困惑しているように見えるプログラマーは答えました：
「どうしてあなたに言えるでしょうか？それは、あなたが餌を与える必要がある人の数、彼らがどれだけ空腹であるか、あなたが提供している他の食べ物、あなたが利用できる米の量などに依存します。」
「その通りです」と偉大なマスターは言いました。
2番目のプログラマーは微笑んで、お辞儀をし、去りました。
...
一日の終わりに向かって、3番目のプログラマーが来て、コードカバレッジについて同じ質問をしました。
「80パーセント、それ以上！」マスターは厳しい声で答え、テーブルの上で拳を叩きました。
3番目のプログラマーは微笑んで、お辞儀をし、去りました。
...
この最後の返信の後、若い見習いが偉大なマスターに近づきました：
「偉大なマスター、今日、私はあなたがコードカバレッジについての同じ質問に3つの異なる答えで答えたことを耳にしました。なぜ？"
偉大なマスターは彼の椅子から立ち上がった：
「新しいお茶を飲みに来て、それについて話しましょう。」
彼らがカップを熱い緑茶で喫煙して満たした後、偉大なマスターは答え始めました：
「最初のプログラマーは新人で、テストを始めたばかりです。現在、彼には多くのコードがあり、テストはありません。彼にはまだまだ長い道のりがある。現時点でのコードカバレッジに焦点を当てることは、憂鬱で非常に役に立たないでしょう。彼は、いくつかのテストの書き込みと実行に慣れるだけでよいです。彼は後で報道を心配することができます。」
「一方、2番目のプログラマーは、プログラミングとテストの両方でかなりの経験があります。私が鍋にどれだけの米の穀物を置くべきかを彼女に尋ねて答えたとき、私は彼女が必要なテストの量が多くの要因に依存していることを理解するのを助けました、そして彼女は私よりもそれらの要因を知っています - それは結局彼女のコードです。単一のシンプルな答えはなく、彼女は真実を処理し、それで働くのに十分賢いです。」
「私はそうだね」と若い見習いは言った、「しかし、単一の簡単な答えがなければ、なぜあなたは3番目のプログラマー「80パーセント」に答えたのですか？」
偉大なマスターはとても激しく笑い、彼の腹は、彼がただ緑茶以上のものを飲んだという証拠を上下にフロップしました。
「3番目のプログラマーは、単純な答えのみを望んでいます。単純な答えがない場合でも…とにかくフォローしません。」
若い見習いとグリズルの偉大なマスターは、瞑想的な沈黙の中でお茶を飲み終えました。
他のヒント
(すべての機能を 100% テストするのではなく) 100% カバレッジが目標である場合、コード カバレッジは誤解を招く指標となります。
- すべての行を 1 回押すと 100% が得られます。ただし、これらの行がヒットする特定のシーケンス (論理パス) のテストを見逃してしまう可能性があります。
- 100% を取得することはできませんでしたが、80%/頻度で使用されたコードパスをすべてテストしました。すべての「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% カバーしたら完了です。
基礎となるプロセスは次のとおりです。
- 私は、考えられるすべての機能とエッジケースを実行するためにテストを作成します (通常はドキュメントに基づいて作業します)。
- コードカバレッジツールを実行します
- カバーされていない行やパス、および重要でないか、到達不可能であると思われるもの (防御的なプログラミングのため) を調査し、カウントしないものとしてマークします。
- 不足している行をカバーするために新しいテストを作成し、それらの特殊なケースが言及されていない場合はドキュメントを改善します。
こうすることで、私と私の共同作業者が将来新しいコードを追加したり、テストを変更したりした場合に、何か重要なことを見逃していないか、つまりカバレッジが 100% を下回ったかどうかを明確に示すことができます。ただし、さまざまなテストの優先順位に対処する柔軟性も提供します。
テスト カバレッジに関する別の逸話を共有したいと思います。
私たちは大規模なプロジェクトを行っており、その中で私はツイッター上で次のように述べました。 700 の単体テストでは、コード カバレッジは 20% しかありません.
スコット・ハンセルマン と答えた 知恵の言葉:
それは正しい20％でしょうか？ユーザーが最もヒットしたコードを表すのは20％ですか？さらに50回のテストを追加し、2％しか追加できません。
またまた私の話に戻りますが、 コードカバレッジに関するテスト 答え。鍋にお米をどのくらい入れればいいですか？場合によります。
これが完璧な世界であれば、コードの 100% が単体テストでカバーされるでしょう。ただし、これは完璧な世界ではないため、時間をどれだけ使えるかが問題です。したがって、特定の割合にはあまり注目せず、重要な領域に重点を置くことをお勧めします。コードが適切に書かれている場合 (または、少なくともその適切な複製)、API が他のコードに公開される重要なポイントがいくつかあるはずです。
これらの API にテスト作業を集中してください。API が 1) 十分に文書化されていること、2) 文書と一致するテスト ケースが記述されていることを確認してください。予期した結果がドキュメントと一致しない場合は、コード、ドキュメント、またはテスト ケースのいずれかにバグがあります。これらはすべて精査するのに適しています。
幸運を！
単体テストが最初から開発を推進する、適切に設計されたシステムの場合、85% はかなり低い数字だと思います。テストしやすいように設計された小規模なクラスであれば、それ以上にカバーするのは難しくありません。
この質問を次のような言葉で却下するのは簡単です。
- カバーされた行はテストされたロジックと同じではないため、パーセンテージを深読みすべきではありません。
確かにその通りですが、コード カバレッジについてはいくつか重要な点があります。私の経験では、この指標は正しく使用すれば実際に非常に役立ちます。そうは言っても、私はすべてのシステムを見たわけではありませんし、コード カバレッジ分析が実際の価値をもたらすことが難しいシステムはたくさんあると思います。コードは非常に異なって見える可能性があり、利用可能なテスト フレームワークの範囲も異なる場合があります。
また、私の推論は主に、非常に短いテスト フィードバック ループに関するものです。私が開発している製品の場合、最短のフィードバック ループは非常に柔軟で、クラス テストからプロセス間のシグナリングまですべてをカバーします。成果物のサブプロダクトのテストには通常 5 分かかりますが、このような短いフィードバック ループの場合、テスト結果 (特にここで見ているコード カバレッジ メトリクス) を使用して、リポジトリ内のコミットを拒否または承認することが実際に可能です。
コード カバレッジ メトリックを使用する場合、満たさなければならない固定 (任意の) パーセンテージだけを設定する必要はありません。 私の意見では、これを行ってもコードカバレッジ分析の本当のメリットは得られません。代わりに、次のメトリクスを定義します。
- ロー ウォーター マーク (LWM)、テスト対象のシステムでこれまでに確認されたカバーされていない回線の最小数
- ハイ ウォーター マーク (HWM)、テスト対象システムでこれまでに確認された最高のコード カバレッジ パーセンテージ
新しいコードは、LWM を超えず、HWM を下回らない場合にのみ追加できます。つまり、コードカバレッジとは、 減らすことは許されない, 、新しいコードもカバーする必要があります。私が「すべき」「すべきではない」とどのように言っているかに注目してください (以下で説明します)。
しかし、これは、もう使い道がなくなった、十分にテストされた古いゴミを掃除することが不可能になることを意味していませんか?はい、だからこそ、これらのことについては現実的である必要があります。ルールを破らなければならない状況もありますが、一般的な日常の統合では、これらのメトリクスが非常に役立つことが私の経験からわかります。それらは次の 2 つの意味を与えます。
テスト可能なコードが昇格されます。新しいコードを追加するときは、すべてのコードをテスト ケースでカバーする必要があるため、コードをテスト可能にするために本当に努力する必要があります。通常、テスト可能なコードは良いことです。
レガシー コードのテスト カバレッジは時間の経過とともに増加しています。新しいコードを追加し、それをテスト ケースでカバーできない場合は、LWM ルールを回避するために、代わりにレガシー コードをカバーすることを試みることができます。この時々必要となる不正行為は、少なくとも、時間の経過とともにレガシー コードの適用範囲が拡大するというプラスの副作用をもたらし、これらのルールの一見厳格な施行が実際には非常に実用的になります。
繰り返しになりますが、フィードバック ループが長すぎる場合、統合プロセスでこのようなものをセットアップすることは完全に非現実的になる可能性があります。
コード カバレッジ メトリックの一般的な利点をさらに 2 つ挙げておきたいと思います。
コード カバレッジ分析は、(静的なコード分析とは対照的に) 動的コード分析の一部です。糸くず)。動的コード分析中に見つかった問題 (purify ファミリなどのツールによる) http://www-03.ibm.com/software/products/en/rational-purify-family) は、初期化されていないメモリ読み取り (UMR)、メモリ リークなどです。 これらの問題は、コードが実行されたテスト ケースでカバーされている場合にのみ検出されます。. 。テスト ケースでカバーするのが最も難しいコードは通常、システム内の異常なケースですが、システムが正常に失敗するようにしたい場合は (つまり、クラッシュの代わりにエラー トレースを使用するなど）、動的コード分析で異常なケースをカバーすることにある程度の労力を費やすこともできます。ほんの少し運が悪いと、UMR がセグメンテーション違反またはそれ以上の事態を引き起こす可能性があります。
人々は新しいコードを 100% 維持することに誇りを持っており、テストの問題についても他の実装の問題と同様の情熱を持って議論します。この関数をよりテストしやすい方法で記述するにはどうすればよいでしょうか?この異常な事件をどうやってカバーしようとしているのか、等々。
完全を期すために、否定的です。
- 多くの開発者が関与する大規模なプロジェクトでは、誰もがテストの天才になれるわけではありません。 一部の人は、コードがテストされていることを証明するためにコード カバレッジ メトリックを使用する傾向がありますが、これは真実とはかけ離れています。, 、この質問に対する他の多くの回答で述べたように。これは、適切に使用すれば優れた利点をもたらす指標の 1 つですが、誤用すると実際には悪いテストにつながる可能性があります。上で述べた非常に有益な副作用とは別に、カバーされた行は、テスト対象のシステムが一部の入力データに対してその行に到達でき、ハングやクラッシュすることなく実行できることを示しているだけです。
チェックイン基準としては、85% が適切な開始点となります。
おそらく、テスト対象のサブシステム/コンポーネントの重要度に応じて、出荷基準としてさまざまな高い基準を選択することになるでしょう。
多くの店はテストを重視していないので、少なくともゼロを上回っていればある程度の価値は認められます。つまり、多くの企業がまだゼロであるのと同じように、おそらくゼロでないことは悪いことではありません。
.Net の世界では、80% が妥当であるとよく言われます。しかし、彼らはソリューションレベルでこれを言います。私はプロジェクトレベルで測定することを好みます。Selenium などを使用している場合や手動テストがある場合は UI プロジェクトには 30% で十分かもしれません。データ層プロジェクトには 20% で十分かもしれません。ただし、完全に必要でない場合でも、ビジネス ルール層では 95% 以上が十分に達成可能かもしれません。したがって、全体のカバレッジはたとえば 60% になる可能性がありますが、重要なビジネス ロジックはそれよりもはるかに高い可能性があります。
こんなことも聞いたことがあります。100% を目指すと 80% に到達します。しかし、80% を目標にすれば、40% に到達します。
結論:80:20 ルールを適用し、アプリのバグ数に基づいて判断してください。
私は cobertura を使用していますが、割合に関係なく、cobertura-check タスクの値を最新の状態に保つことをお勧めします。少なくとも、totallinerate と totalbranchrate を現在のカバレッジのすぐ下まで引き上げ続けます。 一度もない それらの値を下げます。また、Ant ビルド失敗プロパティをこのタスクに関連付けます。カバレッジが不足しているためにビルドが失敗した場合は、誰かが追加したコードを知っていても、それをテストしていないことになります。例：
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
コードの単体テストが十分ではないと考えられ、次に何をテストすればよいかわからないときは、カバレッジを使用して、次に何をテストするかを決定します。
単体テストのカバレッジを増やすと、この単体テストには価値があることがわかります。
これは、カバーされていないコード、50% カバーされているコード、または 97% カバーされているコードにも当てはまります。
コード カバレッジは単なる指標の 1 つです。それ自体、非常に誤解を招く可能性があります (「 www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated）。したがって、目標は 100% のコード カバレッジを達成することではなく、アプリケーションの関連シナリオをすべて確実にテストすることです。
単体テストをかなりの時間行っているのであれば、95% 以上に達しない理由はないと思います。ただし、テストが初めての場合でも、少なくとも、常に 80% で作業してきました。
この数には、プロジェクト内で記述されたコードのみが含まれます (フレームワーク、プラグインなどは除外されます)。また、外部コードへの呼び出しによって記述されたコードのみで構成される特定のクラスも除外される場合があります。この種の呼び出しはモック/スタブ化する必要があります。
一般的に、私が読んだエンジニアリング エクセレンスのベスト プラクティスに関するいくつかの論文から、単体テストでの新しいコードの 80% が最大の成果を生み出すポイントです。この CC% を超えると、費やした労力の割に発生する欠陥の量が少なくなります。これは、多くの大企業で採用されているベスト プラクティスです。
残念ながら、これらの結果のほとんどは企業内部のものであるため、紹介できるような公開文献はありません。
コード カバレッジは優れていますが、それはコード カバレッジから得られるメリットが、コード カバレッジを実現するためのコストや労力を上回る場合に限られます。
私たちはしばらくの間 80% の基準に取り組んできましたが、これを放棄し、代わりにテストに重点を置くことを決定しました。複雑なビジネスロジックなどに集中して、
コード カバレッジの追跡と既存の単体テストの維持に費やす時間が増加したため、この決定が行われました。私たちは、コード カバレッジから得られる利益が、それを達成するために費やさなければならなかった努力よりも少ないとみなされる地点に到達したと感じました。
私は、自動化された受け入れテスト、場合によっては他の統合テスト、および単体テストを組み合わせて使用する BDD を実行することを好みます。私にとっての疑問は、自動テストスイート全体のターゲットカバレッジをどのようにすべきかということです。
それはさておき、答えは方法論、言語、テストおよびカバレッジ ツールによって異なります。Ruby または Python で TDD を実行する場合、100% のカバレッジを維持するのは難しくなく、そうする価値は十分にあります。 90 パーセントのカバレッジよりも 100% のカバレッジを管理する方がはるかに簡単です。 つまり、カバレッジ ギャップが現れたときにそれを埋めるほうが、うまく対応できずにカバレッジを逃したカバレッジ ギャップのリストを管理するよりもはるかに簡単です (TDD をうまく実行している場合、カバレッジ ギャップはまれであり、通常は時間をかける価値があります)。コードが常に露出しているため、リグレッションが発生する可能性があります。
答えはプロジェクトの歴史によっても異なります。私が上記のことが実用的であると感じたのは、最初からそのように管理されたプロジェクトのみです。私は大規模なレガシー プロジェクトのカバレッジを大幅に改善しており、そうする価値はありましたが、過去に戻ってすべてのカバレッジのギャップを埋めるのが現実的であると感じたことはありません。テストされていない古いコードは、正しく理解できるほど十分に理解されていないためです。素早く。
チェックアウト クラップ4j. 。これは、直接的なコード カバレッジよりもわずかに洗練されたアプローチです。コード カバレッジの測定と複雑さの測定を組み合わせて、現在テストされていない複雑なコードを示します。
この難題に対する私の答えは、テストできるコードの行カバレッジを 100% にし、テストできないコードの行カバレッジを 0% にすることです。
私の Python での現在の実践は、.py モジュールを 2 つのフォルダーに分割することです。app1/ と app2/ を実行し、単体テストを実行するときに、これら 2 つのフォルダーのカバレッジを計算し、視覚的に確認します ( しなければならない これをいつか自動化してください)、app1 のカバレッジは 100%、app2 のカバレッジは 0% です。
これらの数値が標準と異なることが判明した場合は、カバレッジが標準に準拠するように調査してコードの設計を変更します。
これは、ライブラリ コードの行カバレッジを 100% 達成することをお勧めできることを意味します。
また、私は時々 app2/ をレビューして、そこでコードをテストできるかどうかを確認し、可能であればそれを app1/ に移動します。
プロジェクトの規模によって大きく異なる可能性があるため、集計カバレッジについてはあまり心配していませんが、一般的には 70% から 90% 以上であることがわかります。
Python を使用すれば、カバレッジを測定しながらアプリを自動的に実行できるスモーク テストを考案でき、できればスモーク テストと単体テストの数値を組み合わせたときに合計 100% を取得できるはずです。
別の視点からカバレッジを表示します。制御の流れが明確でよく書かれたコードは、カバーするのが最も簡単で、最も読みやすく、通常はバグが最も少ないコードです。明確さと網羅性を念頭に置いてコードを作成し、コードと並行して単体テストを作成することで、私見では最高の結果が得られます。
私の意見では、答えは「どれだけ時間があるかによる」です。100%を達成しようとしますが、時間内に達成できなくても大騒ぎしません。
単体テストを作成するときは、実稼働コードを開発するときにかぶる帽子とは異なります。テストされたコードが何を行うと主張しているのか、そしてそれを壊す可能性がある状況は何なのかを考えます。
私は通常、次の基準またはルールに従います。
単体テストは、コードの期待される動作についてのドキュメントの形式である必要があります。特定の入力に対して期待される出力と、クライアントがキャッチしたいと考えられる例外がスローされる可能性があります (コードのユーザーが知っておくべきことは何ですか?)
単体テストは、私がまだ思いつかなかった仮定の条件を発見するのに役立つはずです。(コードを安定して堅牢にする方法は?)
これら 2 つのルールで 100% のカバー率が得られない場合でも、それは問題ありません。しかし、時間があるときに、検出されたブロックと行を分析し、単体テストのないテスト ケースがまだ存在するかどうか、または不必要なコードを削除するためにコードをリファクタリングする必要があるかどうかを判断します。
それはアプリケーションに大きく依存します。たとえば、アプリケーションによっては、大部分が単体テストできない GUI コードで構成されている場合があります。
そんな白黒ルールはあり得ないと思います。
コードは、重要な詳細に特に注意してレビューする必要があります。
ただし、テストされていない場合は、バグがあることになります。
短い答え：60-80%
長い答え:それはプロジェクトの性質に完全に依存すると思います。私は通常、すべての実用的な部分を単体テストすることからプロジェクトを開始します。プロジェクトの最初の「リリース」までに、実行しているプログラミングの種類に基づいて、かなり良い基本パーセンテージが得られるはずです。その時点で、最小限のコード カバレッジの「強制」を開始できます。
コードの重要度に応じて、75% ～ 85% が適切な経験則です。配送コードは、家庭の公共事業などよりも徹底的にテストする必要があります。
これは、アプリケーション開発ライフサイクルのどの段階にいるかによって異なります。
しばらく開発に携わっており、すでに多くのコードが実装されており、コード カバレッジについて考える必要があることに今気づいたばかりの場合は、現在のカバレッジ (存在する場合) を確認し、そのベースラインを使用してコード カバレッジを確認する必要があります。スプリントごとにマイルストーン (またはスプリント期間にわたる平均上昇率) を設定します。これは、エンドユーザーに価値を提供し続けながら、コードの負債を引き受けることを意味します (少なくとも私の経験では、テストが増えてもエンドユーザーは少しも気にしません)新しい機能が表示されない場合は対象範囲となります）。
ドメインによっては、95% を達成することも不合理ではありませんが、平均して 85% ～ 90% のケースを検討することになると言わざるを得ません。
コード カバレッジが正しいことの最良の兆候は、単体テストで修正に役立つ具体的な問題の量が、作成した単体テスト コードのサイズに合理的に対応していることだと思います。
最も重要なことは、長期にわたる報道の傾向を知り、傾向の変化の理由を理解することだと思います。トレンドの変化を良いと見るか悪いと見るかは、その理由を分析するかどうかによって決まります。
数日前までは >80% を目標としていたのですが、多くの生成コードを使用した後は、%age は気にせず、必要なカバレッジについてレビュー担当者に問い合わせるようにしました。
Testivus の投稿から、回答コンテキストは 2 番目のプログラマーであるべきだと思います。実践的な観点からこれを述べましたが、努力すべきパラメータ/目標が必要です。これは、アーキテクチャ、機能 (ユーザー ストーリー) を持ったコードを分析し、数値を導き出すことで、アジャイル プロセスで「テスト」できると考えています。電気通信分野での私の経験に基づくと、60% をチェックするのが適切な値であると言えます。
