unit-testing - 什么可以作为代码覆盖率的替代指标?

标签 unit-testing code-coverage code-metrics

代码覆盖率可能是最具争议的代码指标。有人说,你必须达到 80% 的代码覆盖率,也有人说,这很肤浅,并没有说明你的测试质量。 (参见Jon Limjap's good answer on "What is a reasonable code coverage % for unit tests (and why)?"。)

人们倾向于衡量一切。他们需要比较、基准等。
项目团队需要一个指示,了解他们的测试有多好。

那么代码覆盖率的替代方案是什么?什么是一个比“我接触过这行代码”更好的指标?
有真正的替代方案吗?

最佳答案

如果您正在寻找一些有用的指标来告诉您代码的质量(或缺乏质量),您应该查看以下指标:

  1. 环复杂度
    • 这是衡量方法复杂程度的指标。
    • 通常 10 及以下较好,11-25 较差,较高则较差。
  2. 嵌套深度
    • 这是衡量一个方法中有多少个嵌套作用域的指标。
    • 通常 4 及以下为好,5-8 为差,更高为差。
  3. 关系凝聚力
    • 这是衡量包或程序集中类型的相关程度的指标。
    • 关系凝聚力在某种程度上是一个相对指标,但仍然很有用。
    • 可接受的水平取决于公式。鉴于以下情况:
      • R:包/组件中的关系数量
      • N:封装/组件中的类型数量
      • H:类型之间关系的内聚性
    • 公式:H = (R+1)/N
    • 根据上述公式,可接受的范围为 1.5 - 4.0
  4. 方法缺乏凝聚力 (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/

相关文章:

java - 使用 PowerMock 或您让您的测试对您的设计有多大影响?

c# - 英孚。模拟 ICollection

ios - 单元测试策略,理想的代码覆盖基线

refactoring - 是否可以使用 NDepend 来查找 OOP 语言中的类分区?

.net - 如何使用 Visual Studio 2008 单元测试避免重复的 app.config?

javascript - 测试异步调用会在 Node JS 中抛出未处理的 promise 拒绝

css - 如何使用 chrome dev 协议(protocol)获取 CSS Coverage 数据?

linux - SONAR - 使用 Cobertura 测量代码覆盖率

language-agnostic - 什么是(或应该是)虚函数调用的圈复杂度?

c# - 代码指标 - 静态类和方法计数