如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
当我认为我的代码没有经过足够的单元测试,并且我不确定接下来要测试什么时,我使用覆盖率来帮助我决定接下来要测试什么。
如果我在一个单元测试中增加覆盖率——我知道这个单元测试有价值。
这适用于未覆盖的代码,50%覆盖或97%覆盖。
其他回答
85%是签入标准的一个很好的起点。
我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。
我对这个难题的回答是,对可以测试的代码有100%的行覆盖率,对不能测试的代码有0%的行覆盖率。
我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/,当运行单元测试时,计算这两个文件夹的覆盖率,并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%,而app2的覆盖率为0%。
当/如果我发现这些数字与标准不同,我会调查并改变代码的设计,使覆盖率符合标准。
这意味着我可以建议实现库代码的100%行覆盖率。
我也偶尔检查app2/,看看我是否可以在那里测试任何代码,如果我可以,我将它移动到app1/
现在我不太担心总覆盖率,因为这取决于项目的规模,但通常情况下我看到的是70%到90%以上。
使用python,我应该能够设计一个烟雾测试,可以自动运行我的应用程序,同时测量覆盖率,并有希望获得100%的烟雾测试与单元测试数字的聚合。
如果你已经做了相当长一段时间的单元测试,我认为没有理由不接近95%以上。然而,至少,我总是使用80%的测试,即使是刚开始测试的时候。
这个数字应该只包括在项目中编写的代码(不包括框架、插件等),甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。
看看Crap4j。这是一种比直接代码覆盖稍微复杂一些的方法。它结合了代码覆盖率度量和复杂性度量,然后向您展示哪些复杂的代码目前没有测试。
从另一个角度查看覆盖率:具有清晰控制流的编写良好的代码是最容易覆盖、最容易阅读的,并且通常是错误最少的代码。在编写代码时牢记清晰和可覆盖性,并在编写代码时并行编写单元测试,以我之见,您将得到最好的结果。