测试高级中级 C#

100% 代码覆盖率

Shivprasad koirala

4.83/5 (19投票s)

2013 年 9 月 6 日

CPOL

3分钟阅读

57681

我非常喜欢单元测试，也反对过度单元测试。

我非常喜欢单元测试，也反对过度单元测试。

一些经理自豪地吹嘘他们的代码质量，通过展示 100% 的代码覆盖率屏幕，如下所示。作为一个开发人员，我想知道你的单元测试显示 100% 的代码覆盖率来证明你拥有最好的代码是否真的有必要。

如果你不熟悉代码覆盖率，请阅读这个：- 什么是代码覆盖率？

因为要实现 100% 的代码覆盖率，开发人员必须投入大量精力编写这些单元测试用例并确保所有路径都被覆盖，这绝对是耗时的。

那么，如果 100% 的代码覆盖率真的不值得，那么 80% 更真实，还是 75% 的覆盖率更平衡？

让我们回到基础，问问自己一个基本的测试问题。

我们为什么要测试？

我们进行测试是因为那里有一些复杂的代码可能导致缺陷。所以我们需要确保复杂的代码有一个测试用例，它经过测试并且在它上线之前修复了缺陷。

你能看到高亮显示的“复杂”这个词吗？是的，这就是应该驱动你的代码覆盖率的原因。换句话说，确保你的测试涵盖代码的复杂部分。

好吧，那么定义什么是“复杂”，因为对某人来说复杂的事情对另一个人来说可能很简单。那么下一个问题是我们如何判断代码的复杂性？

大量的代码行是否意味着代码很复杂？

大量的 IF 和 Select case、for 循环是否使代码复杂？那么循环复杂度是否应该被用作基线？如果你对循环复杂度不熟悉，请从这里阅读 http://computerauthor.blogspot.in/2013/09/what-is-cyclomatic-complexity-c-testing.html

大量的继承、聚合和组合是否使代码复杂？

我认为它应该是一个应该考虑到所有上述指标。“可维护性指数”指标就是其中一种，由 Visual Studio 代码度量分析器抛出。可维护性指数指标考虑了所有上述因素，并得出一个介于 0 到 100 之间的数字，值越大越好。

<o:p>

因此，我希望看到较低的可维护性指数代码被覆盖 100%。例如，在下面的报告中，我希望看到“计算”方法具有 100% 的测试覆盖率，因为可维护性为 65。但是“取消”方法的可维护性指数值为 80%，所以也许我会排除它。

<o:p>

如果你看到“取消”方法代码，它只是很多变量的初始化。所以测试这种方法只会增加我的单元测试的努力，而不会有很大的质量提升。

public void Cancel()
{
            Num1 = 0; 
            Num2 = 0;
            Operation = ""; 
            Pie = 3.14;
            Num5 = 0;
            Operation1 = "";
            Num20 = 0;
            Numx = 0;
            OperationStart = "";
            PieMore = 3.145;
            Num6 = 0;
            Operationnew = "";
}

现在看看“计算”方法，它很复杂，有很多“IF”条件等。所以我们希望确保该方法的每个代码分支都被执行。

public int Calculate()
        {
            if (Operation.Length == 0)
            {
                throw new Exception(" Operation not sepecified");
            }
                if (Operation == "+")
                {
                    return Num1 + Num2;
                }
                else if (Operation == "-")
                {
                    return Num1 - Num2;
                }
                else
                {
                    return Num2 * Num1;
                }
                return 0;
 
        }

因此，与其追求 100% 的代码覆盖率，我将遵循以下流程：-

· 了解我的哪些代码的可维护性指数较低，基准可以从低于 80% 的某个地方开始。

· 审查代码的该部分，并检查它是否复杂且关键。

· 如果关键且重要，则应覆盖这部分代码。

所以，与其说“我们希望 100% 的代码覆盖率”，我们可以改述为“我们希望看到复杂且关键的代码有 100% 的代码覆盖率”。

如果这篇文章伤害了任何测试覆盖率纯粹主义者，我很抱歉。