2

現在のコード プロジェクトを TDD に変換していて、あることに気付きました。

class Foo {
    public event EventHandler Test;

    public void SomeFunction() {
        //snip...
        Test(this, new EventArgs());
    }
}

このコードをテストし、十分なテストがあるかどうかを判断するためにコード カバレッジ ツールに依存する場合、2 つの危険が見られます。

  • Testイベントが発生するかどうかをテストする必要があります。これを忘れてしまうと、コード カバレッジ ツールだけではわかりません。
  • すぐに他の人に行きます。

この目的のために、スタートアップ関数にイベント ハンドラーを追加して、次のようにしました。

Foo test;
int eventCount;

[Startup] public void Init() {
    test = new Foo();
    // snip...
    eventCount = 0;
    test.Test += MyHandler;
}

void MyHandler(object sender, EventArgs e) { eventCount++; }

eventCountこれで、イベントが呼び出された場合、イベントが呼び出された回数を簡単に確認できます。かなりきれい。ここで、どのテストでも検出されない小さなバグを突き抜けました。つまり、SomeFunction()イベントを呼び出そうとする前に、イベントにハンドラーがあるかどうかをチェックしません。これにより、null 逆参照が発生しますが、デフォルトですべてのテストにイベント ハンドラーがアタッチされているため、テストによってキャッチされることはありません。ただし、コード カバレッジ ツールは依然として完全なカバレッジを報告します。

これは手元にある私の「実世界の例」にすぎませんが、コードの 100% の「カバレッジ」があっても、これらの種類のエラーの多くがすり抜けてしまう可能性があることに気付きました。 . テストを書くとき、そのようなツールによって報告されたカバレッジを一粒の塩で取る必要がありますか? これらの穴を塞ぐ他の種類のツールはありますか?

4

7 に答える 7

4

私は「一粒の塩でそれを取る」とは言いませんが（コードカバレッジには多くの有用性があります）、自分自身を引用します

TDDとコードカバレッジは万能薬ではありません。

・ブロックカバレッジが100％の場合でも、実行するブロックを選択する条件にエラーが発生します。

・100％のブロックカバレッジ+ 100％のアークカバレッジを使用しても、直線コードにはエラーが発生します。

・100％のブロックカバレッジ+ 100％のアークカバレッジ+ 100％のエラーのない少なくとも1つのパスの直線コードでも、より多くのバグを示す方法でパス/ループを実行する入力データがあります。

（ここから）

改善できるツールがいくつかあるかもしれませんが、コードカバレッジは、製品の品質を保証するための全体的なテスト戦略の一部にすぎないというのが高次のビットだと思います。

于 2008-10-04T13:15:10.797 に答える
4

100% 未満のコード カバレッジは良くありませんが、100% のコード カバレッジが良いというわけではありません。これは必要条件ですが、十分条件ではなく、そのように扱われるべきです。

また、コード カバレッジとパス カバレッジには違いがあることにも注意してください。

void bar(Foo f) {
    if (f.isGreen()) accountForGreenness();
    if (f.isBig()) accountForBigness();
    finishBar(f);
}

大きな緑色の Foo をテスト ケースとしてそのコードに渡すと、100% のコード カバレッジが得られます。しかし、accountForBigness は一部のポインターが非 null であると誤って想定しているため、大きな赤い Foo はシステムをクラッシュさせることを知っています。accountForGreenness への呼び出しをスキップするパスはカバーしていませんが、accountForBigness への呼び出しはスキップしていないため、100% のパス カバレッジはありませんでした。

100% のパス カバレッジがなくても、100% の分岐カバレッジを得ることも可能です。上記のコードでは、大きな緑色の Foo と小さな赤色の Foo を使用した 1 つの呼び出しで前者が返されますが、それでも大きな赤色のバグは検出されません。

この例がこれまでで最高の OO 設計であるというわけではありませんが、コード カバレッジがパス カバレッジを意味するコードを目にすることはめったにありません。また、コードでそれが暗示されている場合でも、ライブラリまたはシステム内のすべてのコードまたはすべてのパスがカバーされ、プログラムが使用できる可能性があることを意味するものではありません。これを行うには、原則として、プログラムのすべての可能な状態を 100% カバーする必要があります (したがって、たとえば、ライブラリまたはシステムでエラーをキャッチするコードにつながる無効なパラメーターを使用して呼び出すことはありません。 ）、これは一般的に実行不可能です。

于 2008-10-04T14:12:53.300 に答える
2

テストを書くとき、そのようなツールによって報告されたカバレッジを一粒の塩で取る必要がありますか?

絶対。カバレッジ ツールは、テスト中に実際に実行されたコード内の行の割合のみを示します。これらの行がどれほど徹底的にテストされたかについては何も述べていません。1 回か 2 回のテストで済むコード行もあれば、幅広い入力範囲でテストする必要があるコード行もあります。カバレッジ ツールでは違いがわかりません。

于 2008-10-04T13:05:09.960 に答える
1

また、テストドライバーが結果の正確性に関して意味のあるアサーションなしでコードを実行しただけの場合、100％のテストカバレッジ自体はあまり意味がありません。

于 2008-10-04T13:09:21.963 に答える
0

カバレッジは、まったくテストされていないコードを識別するためにのみ本当に役立ちます。カバーされているコードについてはあまり説明していません。

于 2008-10-04T13:12:27.603 に答える
0

はい、これが「ライン カバレッジ」と「パス カバレッジ」の主な違いです。実際には、コード パス カバレッジを実際に測定することはできません。静的コンパイル時間チェック、単体テスト、および静的分析と同様に、ライン カバレッジは、高品質のコードを求める際に使用できるもう 1 つのツールです。

于 2008-10-04T14:01:50.640 に答える
0

テストは絶対に必要です。一貫性がなければならないのも実装です。

テストにない方法で何かを実装すると、問題が発生する可能性があります。

テスト対象のデータが、アプリケーションを通過するデータに関連していない場合にも、問題が発生する可能性があります。

はい、コードカバレッジが必要です。しかし、実在の人物による実際のテストほどではありません。

于 2008-10-04T14:23:57.413 に答える