问题描述
在我最近的 Android 项目中，我被要求为单元测试覆盖率设定一个目标.我想知道可实现的合理覆盖率是多少，30%、50% 还是 70%?
In my recent Android project I am asked to set a goal for Unit Test Coverage. I want to know what's the reasonable amount of coverage achievable, 30%, 50% or 70%?
推荐答案
正如评论中所写，没有一个数字，因为它取决于代码.
As was written in the comments, there is no single number, because it depends on the code.
对于自动生成的代码，百分比甚至可以是 0% - 当然，必须测试代码生成器(以及生成器使用的代码片段)，以及控制生成器的源文件.但是，如果这一切都完成了，对生成的代码进行单元测试可能不会带来任何额外的价值.
For automatically generated code the percentage can even be 0% - certainly, the code generator would have to be tested (as well as the code snippets used by the generator), plus the source file that controls the generator. But, if that all is done, unit-testing for the generated code might not bring any additional value.
有时会引入包装器代码来将组件与其依赖项分开.包装器是用来模拟的，但不是用来进行单元测试的.
Sometimes wrapper code is introduced to separate a component from its dependencies. The wrappers are there to be mocked, but not to be unit-tested.
健壮性代码(例如，已明确涵盖所有情况的 switch 语句中的默认情况)无法明智地进行单元测试，因为它无法访问.
Robustness code (like, a default case in a switch statement that already covers all cases explicitly) can not sensibly be unit-tested, because it is unreachable.
有些代码只包含交互，因此应该进行集成测试而不是单元测试.
Some code consists only of interactions and thus should be integration tested rather than unit-tested.
有些代码(可以争论)在单元测试时太琐碎而无法带来任何价值.
Some code (it can be argued) is just too trivial to bring any value when unit-tested.
设定覆盖目标也会带来一些风险:
Setting coverage goals also brings some risks:
因为覆盖琐碎的代码更容易，所以你可能会得到 80% 的代码覆盖率，其中覆盖了 80% 的琐碎代码，但非常困难(因此也可能有缺陷)20% 的代码不是.而且，80% 的覆盖率会给您的管理层一种低风险的错误印象.
Since it is easier to cover trivial code, you may end up with, say, 80% code coverage, where the trivial 80% of the code are covered, but the horribly difficult (and thus also likely buggy) 20% of the code are not. And, the 80% coverage give your management a false impression of low risk.
即使是被覆盖的代码也可能没有经过很好的测试.它甚至可能根本不进行测试 - 仅执行，而不评估结果.
Even code that is covered may not be well tested. It may not even be tested at all - only executed, without evaluation of the results.
不幸的是，很少有质量组织会接受这样的论点.另一方面，这是可以理解的，因为开发往往足以推迟质量活动，以便能够满足客户的最后期限.
Unfortunately, it is seldom that a quality organisation will accept such arguments. Which on the other hand is understandable, because development often enough postpones quality activities to be able to fulfill customer deadlines.
最好的方法是在项目中有一名或多名质量工程师(不是质量经理)，他们受到质量组织的信任，但另一方面不要简单地看覆盖率百分比，但以测试套件的真实质量为准.
The best approach would be to have one or more quality engineers (not quality managers) in the project, who are trusted by the quality organization, but on the other hand do not simply look at coverage percentages, but at the true quality of the test suites.
这篇关于在Android项目中，单元测试可以达到的合理代码覆盖率是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！