如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
代码覆盖率很好,但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能,这些功能在会议中没有讨论)。
我不关心我的代码是否会在测试中被覆盖,但我关心的是我是否会重构我的代码并最终具有不同的行为。因此,100%的功能覆盖率是我的唯一目标。
其他回答
如果你已经做了相当长一段时间的单元测试,我认为没有理由不接近95%以上。然而,至少,我总是使用80%的测试,即使是刚开始测试的时候。
这个数字应该只包括在项目中编写的代码(不包括框架、插件等),甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。
我认为不可能有这样的B/W规则。 应该审查代码,特别注意关键细节。 然而,如果它没有经过测试,它就有一个bug!
许多商店不看重测试的价值,所以如果你高于零,至少有一些价值的升值——所以可以说非零并不是坏事,因为许多仍然是零。
在。net世界中,人们经常引用80%作为合理的。但题目说的是溶液水平。我更喜欢在项目级别进行度量:如果有Selenium等或手动测试,那么UI项目的30%可能就可以了,数据层项目的20%可能就可以了,但是对于业务规则层(如果不是完全必要的话),95%以上可能是可以实现的。因此,总体覆盖率可能是60%,但关键业务逻辑可能更高。
我也听过这样的话:追求100%,你就能达到80%;但是,立志达到80%,你就会达到40%。
底线:应用80:20规则,让应用程序的bug计数来指导你。
看看Crap4j。这是一种比直接代码覆盖稍微复杂一些的方法。它结合了代码覆盖率度量和复杂性度量,然后向您展示哪些复杂的代码目前没有测试。
如果这是一个完美的世界,100%的代码将被单元测试覆盖。然而,因为这不是一个完美的世界,这是一个你有时间做什么的问题。因此,我建议少关注特定的百分比,而更多地关注关键领域。如果你的代码写得很好(或者至少是一个合理的副本),应该有几个关键点将api暴露给其他代码。
将您的测试工作集中在这些api上。确保api是1)良好的文档化的,2)已经编写了与文档相匹配的测试用例。如果预期的结果与文档不匹配,那么您的代码、文档或测试用例中都存在bug。所有这些都是值得调查的。
好运!