“涵盖代码”与“经过代码测试”？ [英] "Code covered" vs. "Code tested"?

问题描述

将我当前的代码项目转换为TDD，我注意到了一些东西。

Converting my current code project to TDD, I've noticed something.

class Foo {
    public event EventHandler Test;

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

测试此代码时，我会看到两种危险并依靠代码覆盖率工具确定您是否有足够的测试。

There are two dangers I can see when testing this code and relying on a code coverage tool to determine if you have enough tests.

• 您应该测试 Test 事件被触发。仅代码覆盖工具不会告诉您您是否忘记了这一点。


• 我将在一秒钟内介绍其他人。

• You should be testing if the Test event gets fired. Code coverage tools alone won't tell you if you forget this.
• I'll get to the other in a second.

为此，我在启动函数中添加了一个事件处理程序，使其看起来像这样：

To this end, I added an event handler to my startup function so that it looked like this:

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（）在尝试之前不会检查事件是否有任何处理程序称呼它。这将导致空解除引用，因为我们的任何测试默认都附带有事件处理程序，所以它永远不会被我们的任何测试捕获。但是，代码覆盖率工具仍然会报告全部覆盖率。

Now I can simply check eventCount to see how many times my event was called, if it was called. Pretty neat. Only now we've let through an insidious little bug that will never be caught by any test: namely, SomeFunction() doesn't check if the event has any handlers before trying to call it. This will cause a null dereference, which will never be caught by any of our tests because they all have an event handler attached by default. But again, a code coverage tool will still report full coverage.

这只是我手头的真实示例，但我发现其中有很多即使代码100％的覆盖，也可能会漏出各种错误，但这仍然无法转化为经过100％的测试。在编写测试时，我们是否应该将这种工具报告的覆盖范围加一点盐？还有其他种类的工具可以解决这些问题吗？

This is just my "real world example" at hand, but it occurs to me that plenty more of these sorts of errors can slip through, even with 100% 'coverage' of your code, this still doesn't translate to 100% tested. Should we take the coverage reported by such a tool with a grain of salt when writing tests? Are there other sorts of tools that would catch these holes?

推荐答案

我不会说拿一点盐 （代码覆盖率有很多实用程序），但引用自己

I wouldn't say "take it with a grain of salt" (there is a lot of utility to code coverage), but to quote myself

TDD和代码覆盖率不是
灵丹妙药：

TDD and code coverage are not a panacea:

·即使100％的
覆盖率，在选择要阻止
的条件下仍然会有错误

· Even with 100% block coverage, there still will be errors in the conditions that choose which blocks to execute.

·即使具有100％的块
覆盖率+ 100％的弧覆盖率，直线中的
仍然会有误差

· Even with 100% block coverage + 100% arc coverage, there will still be errors in straight-line code.

·即使具有100％的块
覆盖率+ 100％的弧形覆盖率+ 100％
几乎没有错误-one-path
直线代码，仍然会有
个输入数据执行
个路径/循环，并表现出更多的
个错误。

· Even with 100% block coverage + 100% arc coverage + 100% error-free-for-at-least-one-path straight-line code, there will still be input data that executes paths/loops in ways that exhibit more bugs.

（来自此处）

虽然有些工具可以提供改进，但我认为高阶位是代码覆盖率只是确保产品质量的整体测试策略的一部分。

While there may be some tools that can offer improvement, I think the higher-order bit is that code coverage is only part of an overall testing strategy to ensure product quality.

这篇关于“涵盖代码”与“经过代码测试”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！