如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
如果你的目标是100%的覆盖率(而不是100%测试所有功能),那么代码覆盖率就是一个误导的指标。
你可以通过一次命中所有的线来获得100%。然而,您仍然可能错过测试这些行命中的特定序列(逻辑路径)。 您不能得到100%,但仍然测试了所有80%/频率使用的代码路径。测试每个“抛出ExceptionTypeX”或类似的防御性编程保护是“有就好”而不是“必须”
所以要相信你自己或你的开发人员是彻底的,并覆盖他们代码中的每一条路径。要务实,不要追求神奇的100%覆盖率。如果你用TDD开发你的代码,你应该得到90%以上的覆盖率作为奖励。使用代码覆盖来突出你错过的代码块(如果你使用TDD就不应该发生这种情况。因为您编写代码只是为了通过测试。没有伙伴测试,任何代码都不能存在。)
其他回答
我对这个难题的回答是,对可以测试的代码有100%的行覆盖率,对不能测试的代码有0%的行覆盖率。
我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/,当运行单元测试时,计算这两个文件夹的覆盖率,并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%,而app2的覆盖率为0%。
当/如果我发现这些数字与标准不同,我会调查并改变代码的设计,使覆盖率符合标准。
这意味着我可以建议实现库代码的100%行覆盖率。
我也偶尔检查app2/,看看我是否可以在那里测试任何代码,如果我可以,我将它移动到app1/
现在我不太担心总覆盖率,因为这取决于项目的规模,但通常情况下我看到的是70%到90%以上。
使用python,我应该能够设计一个烟雾测试,可以自动运行我的应用程序,同时测量覆盖率,并有希望获得100%的烟雾测试与单元测试数字的聚合。
85%是签入标准的一个很好的起点。
我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。
当我认为我的代码没有经过足够的单元测试,并且我不确定接下来要测试什么时,我使用覆盖率来帮助我决定接下来要测试什么。
如果我在一个单元测试中增加覆盖率——我知道这个单元测试有价值。
这适用于未覆盖的代码,50%覆盖或97%覆盖。
如果你已经做了相当长一段时间的单元测试,我认为没有理由不接近95%以上。然而,至少,我总是使用80%的测试,即使是刚开始测试的时候。
这个数字应该只包括在项目中编写的代码(不包括框架、插件等),甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。
直到几天前,我们的目标是>的80%,但在我们使用了大量生成代码后,我们并不关心%age,而是让审核人员决定覆盖率要求。