Skip to content

[自动合并 P2-3] diff coverage 门槛 #88

Description

@randypanding

目标

新增 diff coverage 门槛:本次变更行的覆盖率必须达标(如 ≥80%),而非全局覆盖率。全局覆盖率会被大 PR 稀释,挡不住"顺手加 200 行无测试代码"。

背景(源自 #81 §4.1)

无人 review 时,"测试还在跑且绿"不等于"新代码被测过"。diff coverage 只问一个问题:这个 PR 新增/修改的行,有没有被测试执行到。这是把"没坏"升级为"做对了"的关键一维。

涉及文件

  • CI-Workflows/.github/workflows/check.yml(测试 job 产出覆盖率报告)
  • CI-Workflows/scripts/diff-coverage.sh 或采用现成工具(如 diff-cover for Python、go tool cover + diff 交集),选型按各仓语言栈定
  • governance/policy/testing.yaml(阈值声明,建议 80%,允许按仓覆盖)
  • 各业务仓 gate needs 链

执行步骤

  1. 选型:盘点受管仓语言栈(template-service、agent-platform 等),为每种栈确定覆盖率工具与 diff 交集算法,优先现成成熟工具。
  2. 实现:测试 job 产出覆盖数据 → diff coverage 计算 job 只对 PR 变更行求覆盖率 → 低于阈值红。
  3. 变更行覆盖不了的情形(配置文件、生成代码、文档)按扩展名/路径声明豁免清单(进 policy,可被对账,不得由 PR 自行扩大——豁免清单变更走 ADR)。
  4. 阈值进 policy/testing.yaml,接入 gate needs 链。

验收标准

  • 变更行覆盖率 ≥ 阈值的 PR 绿,< 阈值的红,错误信息给出未覆盖行清单。
  • 全局覆盖率高但 diff 覆盖低的 PR 红(证明用的是 diff 口径)。
  • 豁免清单内文件不参与计算;豁免清单本身的修改触发 ADR 要求。

测试方法(预先指定)

T1 低于阈值(负向):在测试仓 PR 新增 20 行无测试源码 → 断言 gate 红,输出含未覆盖行号列表,人工抽查行号正确。

T2 达标(正向):PR 新增 20 行源码 + 覆盖全部新行的测试 → 断言绿。

T3 稀释攻击(核心,负向):构造一个全局覆盖率仍然很高(如 90%)但本次新增行覆盖率很低(如 30%)的 PR → 断言红。此用例证明口径是 diff 而非全局——若该 PR 变绿,说明实现错了。

T4 部分覆盖边界:新行覆盖率恰好等于阈值(如 80.0%)→ 断言绿;79.9% → 断言红(边界语义写入 policy)。

T5 豁免清单:PR 只改豁免清单内文件(如 markdown/配置)→ 断言绿;PR 试图把某源码目录加进豁免清单且无 ADR → 断言红(豁免清单变更受 ADR 保护)。

T6 工具正确性(单元级):准备 3 个预标注 fixture(已知 diff 行集与已知执行行集),断言工具输出的 diff 覆盖率与人工计算值完全一致(±0.1%)。

依赖

  • P1-3(aggregator 模式)
  • P2-1 / P2-2(同批接入各仓 caller)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    auto-merge自动合并计划(#81)工作卡gateGate 工作流相关

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions