代码覆盖率可能是最具争议的代码指标。有人说,你必须达到 80% 的代码覆盖率,也有人说,这很肤浅,并没有说明你的测试质量。 (参见Jon Limjap's good answer on "What is a reasonable code coverage % for unit tests (and why)?"。)
人们倾向于衡量一切。他们需要比较、基准等。
项目团队需要一个指示,了解他们的测试有多好。
那么代码覆盖率的替代方案是什么?什么是一个比“我接触过这行代码”更好的指标?
有真正的替代方案吗?
最佳答案
如果您正在寻找一些有用的指标来告诉您代码的质量(或缺乏质量),您应该查看以下指标:
- 环复杂度
- 这是衡量方法复杂程度的指标。
- 通常 10 及以下较好,11-25 较差,较高则较差。
- 嵌套深度
- 这是衡量一个方法中有多少个嵌套作用域的指标。
- 通常 4 及以下为好,5-8 为差,更高为差。
- 关系凝聚力
- 这是衡量包或程序集中类型的相关程度的指标。
- 关系凝聚力在某种程度上是一个相对指标,但仍然很有用。
- 可接受的水平取决于公式。鉴于以下情况:
- R:包/组件中的关系数量
- N:封装/组件中的类型数量
- H:类型之间关系的内聚性
- 公式:H = (R+1)/N
- 根据上述公式,可接受的范围为 1.5 - 4.0
- 方法缺乏凝聚力 (LCOM)
- 这是衡量类(class)凝聚力的指标。
- 类的内聚性衡量的是每个方法引用的字段数量。
- 很好地表明您的类(class)是否符合单一职责原则。
- 公式:LCOM = 1 - (sum(MF)/M*F)
- M:类中方法的数量
- F:类中实例字段的数量
- MF:类中访问特定实例字段的方法数量
- sum(MF):所有实例字段的 MF 之和
- 完全内聚的类的 LCOM 为 0。
- 完全非内聚的类的 LCOM 为 1。
- 越接近 0,您的类就越有凝聚力和可维护性。
这些只是 NDepend(一个 .NET 指标和依赖关系映射实用程序)可以为您提供的一些关键指标。我最近在代码指标方面做了很多工作,这 4 个指标是我们发现最有用的核心关键指标。然而,NDepend 提供了其他几个有用的指标,包括传出和传入耦合以及抽象性和不稳定性,它们结合起来可以很好地衡量代码的可维护性(以及您是否处于 NDepend 所说的“痛苦区”或“痛苦区”)。无用。)
即使您不使用 .NET 平台,我也建议您查看 NDepend metrics page 。其中有很多有用的信息,您可以使用它们在您开发的任何平台上计算这些指标。
关于unit-testing - 什么可以作为代码覆盖率的替代指标?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1047758/