如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
我认为最重要的是了解随着时间的推移,覆盖率的趋势是什么,并理解趋势变化的原因。你认为趋势的变化是好是坏取决于你对原因的分析。
其他回答
我最喜欢的代码覆盖率是100%。星号之所以出现,是因为我更喜欢使用工具,允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行,我就完成了。
底层流程是:
我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径,以及我认为不重要或无法到达的线或路径(由于防御性编程),我将其标记为不算数 我编写了新的测试来覆盖缺失的行,并在没有提到这些边缘情况时改进文档。
这样,如果我和我的合作者将来添加新代码或更改测试,就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而,它也提供了处理不同测试优先级的灵活性。
当我认为我的代码没有经过足够的单元测试,并且我不确定接下来要测试什么时,我使用覆盖率来帮助我决定接下来要测试什么。
如果我在一个单元测试中增加覆盖率——我知道这个单元测试有价值。
这适用于未覆盖的代码,50%覆盖或97%覆盖。
根据代码的关键程度,75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。
如果你已经做了相当长一段时间的单元测试,我认为没有理由不接近95%以上。然而,至少,我总是使用80%的测试,即使是刚开始测试的时候。
这个数字应该只包括在项目中编写的代码(不包括框架、插件等),甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。
代码覆盖率很好,但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能,这些功能在会议中没有讨论)。
我不关心我的代码是否会在测试中被覆盖,但我关心的是我是否会重构我的代码并最终具有不同的行为。因此,100%的功能覆盖率是我的唯一目标。