GitHub把覆盖率门禁开放给API后，最先暴露的可能不是低覆盖，而是各仓库标准完全不同

摘要：GitHub 9月18日支持用REST API管理代码覆盖率规则。本文说明怎样把最小覆盖率、最大下降幅度、例外和规则漂移纳入测试。

一个组织有40个仓库。A仓要求覆盖率80%，B仓只要新增代码不下降，C仓因为迁移时临时关过一次门禁，半年后没人记得打开。

9月18日，GitHub宣布可以通过REST API管理Restrict code coverage规则：既能要求最低行覆盖率，也能限制一次PR允许下降的最大幅度。过去依赖网页配置的规则，现在可以进入基础设施即代码流程。

这件事的价值不是“少点几下页面”，而是质量标准终于可以被版本化、审查和回归。

覆盖率门禁要分基线和变化量

遗留系统可能只有55%，直接要求80%只会让团队关闭规则。更实际的做法是同时设置两条线：新仓库守最低绝对值；遗留仓库先守“不得下降”，再按模块逐步提高。

规则配置可以长这样：

desired = {
    "payment-api": {"min_line": 85, "max_drop": 0.5},
    "legacy-billing": {"min_line": 55, "max_drop": 0.0},
}

def drift(actual, desired):
    return {k: desired[k] for k in desired if actual.get(k) != desired[k]}

assert drift({"payment-api": {"min_line": 80, "max_drop": 1.0}}, desired)

定时拉取实际Ruleset与仓库清单对比，能发现规则被手工修改、仓库漏纳管或例外过期。

覆盖率高不等于测试有效

API化门禁更容易批量铺开，也更容易形成错误安全感。AI Coding可以迅速补出大量只执行代码、不验证业务结果的测试，把行覆盖率推上去。

因此覆盖率门禁旁边至少还要放两个检查：关键业务变异测试是否存活；支付、退款、权限等核心不变量是否有明确断言。覆盖率回答“跑到了吗”，不回答“错了能发现吗”。

例外也必须是代码

允许某仓库临时降低标准时，配置里要有责任人、原因和到期日。CI发现到期例外就失败，不能靠人记。

规则本身也需要测试

把配置交给API并不代表配置一定生效。至少准备四条验证：覆盖率高于阈值时允许合并；低于绝对阈值时拒绝；总体覆盖率仍高但本次下降超过容忍度时拒绝；没有上传覆盖率报告时不能被误判为100%或自动跳过。

还要验证分支和仓库选择条件。很多规则漂移不是阈值写错，而是Pattern没有覆盖新建仓库、默认分支改名后规则失效，或Bot账号意外进入绕过清单。

对于批量治理，可以先在报告模式运行一周：不阻断合并，只记录哪些PR会失败。然后把失败分为真正低质量、历史基线问题、报告上传故障和规则选错对象。前两类改测试，后两类改治理配置。

三种不能被覆盖率“洗白”的测试

第一种是没有业务断言，只调用函数就结束；第二种是Mock掉核心逻辑，只证明Mock按预期返回；第三种是大量容易覆盖的分支提高平均值，却回避支付、权限等关键路径。

对核心模块，可以额外设置变异得分、关键不变量用例和changed-lines coverage。这样AI生成测试想靠执行无关代码抬高数字，也很难绕过三层证据。

把规则API接入后，测试负责人每周最值得看的不是全组织平均覆盖率，而是三张表：哪些仓库规则漂移、哪些PR刚好贴线通过、哪些例外即将到期。这比一张漂亮的80%大盘更能提前发现风险。