如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?
请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)
当前回答
我对这个难题的回答是,对可以测试的代码有100%的行覆盖率,对不能测试的代码有0%的行覆盖率。
我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/,当运行单元测试时,计算这两个文件夹的覆盖率,并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%,而app2的覆盖率为0%。
当/如果我发现这些数字与标准不同,我会调查并改变代码的设计,使覆盖率符合标准。
这意味着我可以建议实现库代码的100%行覆盖率。
我也偶尔检查app2/,看看我是否可以在那里测试任何代码,如果我可以,我将它移动到app1/
现在我不太担心总覆盖率,因为这取决于项目的规模,但通常情况下我看到的是70%到90%以上。
使用python,我应该能够设计一个烟雾测试,可以自动运行我的应用程序,同时测量覆盖率,并有希望获得100%的烟雾测试与单元测试数字的聚合。
其他回答
85%是签入标准的一个很好的起点。
我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。
根据代码的关键程度,75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。
这取决于您所处的应用程序开发生命周期的哪个阶段。
If you've been at development for a while and have a lot of implemented code already and are just now realizing that you need to think about code coverage then you have to check your current coverage (if it exists) and then use that baseline to set milestones each sprint (or an average rise over a period of sprints), which means taking on code debt while continuing to deliver end user value (at least in my experience the end user doesn't care one bit if you've increased test coverage if they don't see new features).
根据你的领域,达到95%并不是不合理的,但我不得不说,平均而言,你将看到的平均情况是85%到90%。
代码覆盖率是很好的,但前提是你从中得到的好处超过了实现它的成本/努力。
一段时间以来,我们一直在努力达到80%的标准,但我们刚刚决定放弃这个标准,转而更专注于我们的测试。专注于复杂的业务逻辑等,
这个决定是由于我们花在追逐代码覆盖率和维护现有单元测试上的时间越来越多。我们觉得我们已经到达了这样一个点:我们从代码覆盖率中得到的好处被认为比我们为实现它所付出的努力要少。
我更喜欢做BDD,它使用自动化验收测试、可能还有其他集成测试和单元测试的组合。对我来说,问题是自动化测试套件作为一个整体的目标覆盖率应该是多少。
That aside, the answer depends on your methodology, language and testing and coverage tools. When doing TDD in Ruby or Python it's not hard to maintain 100% coverage, and it's well worth doing so. It's much easier to manage 100% coverage than 90-something percent coverage. That is, it's much easier to fill coverage gaps as they appear (and when doing TDD well coverage gaps are rare and usually worth your time) than it is to manage a list of coverage gaps that you haven't gotten around to and miss coverage regressions due to your constant background of uncovered code.
答案也取决于项目的历史。我发现上述方法只适用于从一开始就以这种方式管理的项目。我已经极大地改进了大型遗留项目的覆盖率,这样做是值得的,但是我从来没有发现回过头去填补每个覆盖率空白是可行的,因为旧的未经测试的代码不能很好地理解,不能正确和快速地完成这些工作。