如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
我使用cobertura,无论百分比是多少,我都建议保持cobertura检查任务中的值是最新的。至少,不断提高totallinerate和totalbranrate到刚好低于你当前的覆盖率,但永远不要降低这些值。还将Ant构建失败属性绑定到此任务。如果构建因为缺乏覆盖而失败,那么您知道有人添加了代码,但没有测试它。例子:
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
其他回答
根据代码的关键程度,75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。
我对这个难题的回答是,对可以测试的代码有100%的行覆盖率,对不能测试的代码有0%的行覆盖率。
我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/,当运行单元测试时,计算这两个文件夹的覆盖率,并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%,而app2的覆盖率为0%。
当/如果我发现这些数字与标准不同,我会调查并改变代码的设计,使覆盖率符合标准。
这意味着我可以建议实现库代码的100%行覆盖率。
我也偶尔检查app2/,看看我是否可以在那里测试任何代码,如果我可以,我将它移动到app1/
现在我不太担心总覆盖率,因为这取决于项目的规模,但通常情况下我看到的是70%到90%以上。
使用python,我应该能够设计一个烟雾测试,可以自动运行我的应用程序,同时测量覆盖率,并有希望获得100%的烟雾测试与单元测试数字的聚合。
代码覆盖率很好,但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能,这些功能在会议中没有讨论)。
我不关心我的代码是否会在测试中被覆盖,但我关心的是我是否会重构我的代码并最终具有不同的行为。因此,100%的功能覆盖率是我的唯一目标。
许多商店不看重测试的价值,所以如果你高于零,至少有一些价值的升值——所以可以说非零并不是坏事,因为许多仍然是零。
在。net世界中,人们经常引用80%作为合理的。但题目说的是溶液水平。我更喜欢在项目级别进行度量:如果有Selenium等或手动测试,那么UI项目的30%可能就可以了,数据层项目的20%可能就可以了,但是对于业务规则层(如果不是完全必要的话),95%以上可能是可以实现的。因此,总体覆盖率可能是60%,但关键业务逻辑可能更高。
我也听过这样的话:追求100%,你就能达到80%;但是,立志达到80%,你就会达到40%。
底线:应用80:20规则,让应用程序的bug计数来指导你。
从另一个角度查看覆盖率:具有清晰控制流的编写良好的代码是最容易覆盖、最容易阅读的,并且通常是错误最少的代码。在编写代码时牢记清晰和可覆盖性,并在编写代码时并行编写单元测试,以我之见,您将得到最好的结果。