如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?

请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)


当前回答

我对这个难题的回答是,对可以测试的代码有100%的行覆盖率,对不能测试的代码有0%的行覆盖率。

我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/,当运行单元测试时,计算这两个文件夹的覆盖率,并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%,而app2的覆盖率为0%。

当/如果我发现这些数字与标准不同,我会调查并改变代码的设计,使覆盖率符合标准。

这意味着我可以建议实现库代码的100%行覆盖率。

我也偶尔检查app2/,看看我是否可以在那里测试任何代码,如果我可以,我将它移动到app1/

现在我不太担心总覆盖率,因为这取决于项目的规模,但通常情况下我看到的是70%到90%以上。

使用python,我应该能够设计一个烟雾测试,可以自动运行我的应用程序,同时测量覆盖率,并有希望获得100%的烟雾测试与单元测试数字的聚合。

其他回答

85%是签入标准的一个很好的起点。

我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。

我使用cobertura,无论百分比是多少,我都建议保持cobertura检查任务中的值是最新的。至少,不断提高totallinerate和totalbranrate到刚好低于你当前的覆盖率,但永远不要降低这些值。还将Ant构建失败属性绑定到此任务。如果构建因为缺乏覆盖而失败,那么您知道有人添加了代码,但没有测试它。例子:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

我最喜欢的代码覆盖率是100%。星号之所以出现,是因为我更喜欢使用工具,允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行,我就完成了。

底层流程是:

我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径,以及我认为不重要或无法到达的线或路径(由于防御性编程),我将其标记为不算数 我编写了新的测试来覆盖缺失的行,并在没有提到这些边缘情况时改进文档。

这样,如果我和我的合作者将来添加新代码或更改测试,就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而,它也提供了处理不同测试优先级的灵活性。

这在很大程度上取决于您的应用程序。例如,一些应用程序主要由不能进行单元测试的GUI代码组成。

从Testivus的帖子中,我认为答案上下文应该是第二个程序员。

从实际的角度来看,我们需要争取参数/目标。

我认为这可以在敏捷过程中进行“测试”,方法是分析我们拥有的代码、架构、功能(用户故事),然后得出一个数字。根据我在电信领域的经验,我认为60%是一个很好的值。