如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
我最喜欢的代码覆盖率是100%。星号之所以出现,是因为我更喜欢使用工具,允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行,我就完成了。
底层流程是:
我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径,以及我认为不重要或无法到达的线或路径(由于防御性编程),我将其标记为不算数 我编写了新的测试来覆盖缺失的行,并在没有提到这些边缘情况时改进文档。
这样,如果我和我的合作者将来添加新代码或更改测试,就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而,它也提供了处理不同测试优先级的灵活性。
其他回答
我最喜欢的代码覆盖率是100%。星号之所以出现,是因为我更喜欢使用工具,允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行,我就完成了。
底层流程是:
我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径,以及我认为不重要或无法到达的线或路径(由于防御性编程),我将其标记为不算数 我编写了新的测试来覆盖缺失的行,并在没有提到这些边缘情况时改进文档。
这样,如果我和我的合作者将来添加新代码或更改测试,就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而,它也提供了处理不同测试优先级的灵活性。
85%是签入标准的一个很好的起点。
我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。
代码覆盖率只是另一个度量。就其本身而言,它可能非常具有误导性(参见www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated)。因此,您的目标不应该是实现100%的代码覆盖率,而是要确保您测试了应用程序的所有相关场景。
我使用cobertura,无论百分比是多少,我都建议保持cobertura检查任务中的值是最新的。至少,不断提高totallinerate和totalbranrate到刚好低于你当前的覆盖率,但永远不要降低这些值。还将Ant构建失败属性绑定到此任务。如果构建因为缺乏覆盖而失败,那么您知道有人添加了代码,但没有测试它。例子:
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
直到几天前,我们的目标是>的80%,但在我们使用了大量生成代码后,我们并不关心%age,而是让审核人员决定覆盖率要求。