この種のフレーズは、開発狂信者、さまざまなユーティリティの売り手、便利なツールのユーザーなど、まったく異なる人々から聞くことができます。 私のマネージャーは、何か新しいことを試してみたいときにも聞いています。
ただし、ツールの取扱説明書には通常「禁忌」セクションが含まれていません;ユーティリティを使用する価値がない状況は示されていません。 一方、このようなセクションは、失敗した実験の時間を大幅に節約できます。
今日、コードカバレッジ（CC）で石を投げています。 かなり有用なメトリック。その下には、不十分に文書化されたいくつかのレーキがあります。
「嘘がある、露骨な嘘がある
統計があります。」
SonarQubeの作成者はこれを完全に理解していますが、 SonarQube には多数のCCメトリックスがあるという理由があります 。 DevExpressのCCを使用して統計を中断します。メトリックは1つだけです。
問題1.典型的なテストが間違っています。 多数の引数チェックを使用してメソッドをテストします。
public static Hash Example1_IfThen(int arg) { if(arg == 0) { throw new ArgumentException("0 argument"); } if (arg == 1) { throw new ArgumentException("1 argument"); } if (arg == 2) { throw new ArgumentException("2 argument"); } return new Hash(new Hash(arg + 42) + 13); } ... [TestMethod, ExpectedException(typeof(ArgumentException))] public void Example1_IfThen_0() { Program.Example1_IfThen(0); } [TestMethod, ExpectedException(typeof(ArgumentException))] public void Example1_IfThen_2() { Program.Example1_IfThen(2); } [TestMethod, ExpectedException(typeof(ArgumentException))] public void Example1_IfThen_1() { Program.Example1_IfThen(1); }
メソッドは83％がテストでカバーされており、通常は自動ビルドに十分です 。 技術的に議論することはありません。ほとんどのコードはテストでカバーされていますが、主なシナリオはテストの影響を受けません。 テストはコードの最も単純な部分を対象としており、最も重要な部分は対象としていません。
問題2.必要なのではなく、実際のコードを測定します。
public static int Example2_IncompleteLogic(IEnumerable<int> arg) { return arg .Where(elem => elem != 2) .Where(elem => elem != 3) .Count(); } ... [TestMethod] public void OneTestToCoverAll() { // Arrange - collection with one element '4' var arg = new List<int> { 4 }; // Act var result = Program.Example2_IncompleteLogic(arg); // Assert Assert.AreEqual(1, result); }
テストメソッドにはnull引数のチェックは含まれていませんが、カバレッジは100％です。 時々人々は忘れます：コードカバレッジはコードカバレッジメトリックであり、要件閉鎖メトリックではありません。 メソッドにロジックがない場合（メソッドは問題を解決するほど複雑ではない）-CCはこれを表示しません。
100％のカバレッジは、プログラムのパフォーマンスを保証するものではありません 。 それを不条理のポイントに持ち込む：空のメソッドは基本的に100％カバーされます。 空でないメソッドは、アサートなしで100％テストされます。
問題3.楽観。 前の問題のわずかに異なる症状。 ご覧のとおり、1つのテストがコードの100％をカバーします。 メソッドを書き直して、（パフォーマンスを向上させるために）LINQを削除してみましょう。
var result = 0; foreach(var elem in arg) { if(elem == 2 || elem == 3) { continue; } else { result++; } } return result;
73％しかカバーしていません。 機能は変更されておらず、メトリックは低下しています。 それだけでなく、100％のカバレッジはプログラムのパフォーマンスを保証するものではなく、これらの100％は偽物である可能性があります 。 結論：
サイドオブザベーション：この場合、技術的な実装にジャムを置くことができます、理論的には匿名メソッドelem => elem！= 2はelem => if（elem！= 2）return true else return false; 、元のメソッドのカバレッジを最大73％修正します。 確かに、このようなアプローチには、現在便利なUIの複雑さが必要になります。
結果：使用するツールは、必要な機能をすべて備えているとは限りません。 些細なことでもあります。
問題4.責任の移転。
public static void MakeEverythingWell() { OuterLib.MakeEverythingWell(); }
この方法は、1つのテストで100％カバーされています。 さらに、OuterLibライブラリの適用範囲は、それを追加した人の良心にあります。 または更新されました。 3年前、CCの導入前。 解雇前。
事実を再度述べなければなりません。カバレッジの100％がプログラムの操作性を保証しないだけでなく、これらの100％は偽物である可能性があります。
純粋にコードポイントに加えて、CC結果の処理に特化したいくつかの主張があります。
クレーム0、すべてに知られています。 100％のカバレッジ。 100％のカバレッジなし-ビルド承認なし。 問題は、カバレッジの最初の割合は比較的単純ですが、最後は...特にコードの一部が生成される場合です。 または到達不能（2日以内に使用するVasya用に作成されたため）。 または、単に理論的に達成可能で、数週間を計算する\を選択する例（これは数学で作業しているときに起こります）。 要するに、ほとんどのチーム（一般にCCをCIに統合するチーム）は、必要なカバレッジの60 \ 70 \ 80％で停止します。
クレーム1、物議を醸す。 デッドコードカバレッジ。 私の記憶では、PVSの同僚によるMirandの 検証中に、同様の問題が特に顕著でした。 コメントは非常に感情的ですが、議論の一部はデッドコードに関するものでした。見つかった診断の一部は、（放棄された）プラグインを指していますが、 コアではありません。
問題は、デッドコードにCodeCoverageが必要ですか？ 一方で、デッドコードは問題であり、注意が促されます。 一方、デッドコードは本番環境に影響を与えません。したがって、CCメトリックに影響を与えることは価値がありますか？
主張2.コードの重要性。 問題の拡大1.私のプロジェクトには、「支払い」と「交渉」という2つの注目すべきコントローラーがあります。 「支払い」はクライアントにとって重要であり、「匿名」は「交渉」を使用する一方で、「80％のカバレッジ」の要件に完全に同意します。 年ごと。 そして彼女は2年間変わっていません。 質問：半分機能しなくなった機能のテストを書くのはなぜですか？ 自動アセンブリ承認のために 80％バッジを取得するだけですか？
クレーム3、不可能。 成果としてのメトリック。 これは、カバーされている内容を誰もチェックしない場合です。 コード行の支払いに関する話を覚えていますか？ カバレッジを向上させるために不要なコードを作成した人について聞いたことがあります。
クレーム4.メトリック「無料」。 管理者が要件を「80％でコードをカバーする」と落とすと、開発者は素直に同意します。 プロジェクトは1回限りです。 またはプロトタイプ。 または、鼻の締め切り。 または、単一のテストなしで、巨大な
コードをテストでカバーするには時間がかかります！ コーティングも測定すると、テスト時間が長くなる可能性があります（ただし、低下する可能性があります）。 そのため、チームがプロジェクトを予定通りに完了できず、カバレッジの80％に達した場合、管理者と開発者の間で障害を共有できます。 ホリバーにとって、罪悪感の境界線の問題は提起されるべきではありません。
最後に。 繰り返しになりますが、SSは意外ではありますが、有用な指標です。 レポートの数字に対する盲目的な欲求がない場合、それは本当にコード制御に役立ちます。