CI 里的测试:什么时候跑什么

CI 是测试的执行引擎

先说清楚 CI 给测试带来的三个质变,这是它值得单独一章的原因:

分层流水线:快的在前,慢的在后

第 8 章的"测试选择台"Demo,画的就是这件事。核心原则是快速失败:把又快又能抓大错的测试放最前面,让明显的问题尽早、尽廉价地暴露。

分片并行:把 20 分钟压成 3 分钟

当测试多到一台机器跑要 20 分钟,答案不是"忍",而是分片(sharding):把测试拆成 N 份,丢到 N 台机器上同时跑。测试天生适合并行 —— 只要它们真的独立(FIRST 的 I,第 5 章)。

必需检查:红了就是进不来

门禁要真的是门禁,得配上仓库的分支保护(branch protection):把关键的 CI 检查设为必需(required)。这样,只要这些检查是红的,PR 的合并按钮就是灰的 —— 没有人能绕过,包括你自己在赶时间的时候。

这一步很关键,因为它把"要不要理会红灯"这个需要意志力的决定,变成了一个系统强制的规则。意志力会在 deadline 前失守,规则不会。

flaky 隔离区:别让一个抖动的测试卡死所有人

把第 17 章的 flaky 治理,落到 CI 的具体机制上:

进阶:只跑改动相关的测试

大项目里,还有一招能进一步提速:测试影响分析(test impact analysis) —— 根据这次改了哪些文件,只跑可能受影响的那部分测试。改了一个孤立的工具函数,没必要跑整个 App 的端到端。这需要构建系统支持依赖分析(Gradle、Bazel 都有相关能力),属于规模上来后的优化,但方向和整章一致:用最小的代价,拿到足够的信心。

AI 时代:CI 是 AI 代码的最后一道闸

一份真实的分层流水线

把这一章的原则落成一份能抄的 GitHub Actions 配置。注意三个要点:冒烟前置、分片矩阵、以及分片结果如何汇总:

jobs:
  smoke:                              # 关卡一:最前、最快
    runs-on: ubuntu-latest
    steps: [ { run: ./gradlew smokeTest } ]

  unit:                               # 关卡二:分片并行
    needs: smoke                      # 冒烟绿了才跑
    strategy:
      matrix: { shard: [1, 2, 3, 4] } # ← 4 台机器同时跑
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew test -Pshard=${{ matrix.shard }} -PtotalShards=4

  integration:
    needs: unit
    runs-on: ubuntu-latest
    steps: [ { run: ./gradlew integrationTest } ]

  gate:                               # 汇总:所有关卡都绿,才算这个 PR 通过
    needs: [smoke, unit, integration]
    runs-on: ubuntu-latest
    steps: [ { run: echo "all green" } ]

把 gate 这个「汇总」任务设为唯一的必需检查,是个实用技巧:分支保护只认 gate 一个,而 gate 依赖前面所有关卡。这样你增删测试任务时,不用每次去改分支保护规则,只要它们挂在 gate 的 needs 里就行。

合并队列:别让「各自绿」骗了你

分层流水线还挡不住一类阴险的问题:PR A 和 PR B 各自跑测试都绿,但它们合到一起就冲突(A 删了一个函数,B 刚好在别处调了它)。两个 PR 分别基于旧主干测的,谁也没测过「A+B 合并后」的状态。

流水线搭好了,但它跑的测试会随时间腐烂 —— 越来越慢、越来越难懂、越来越难改。倒数第二章讲测试的可维护性:怎么让测试跑得快、活得久,而不是变成一堆没人敢动、又拖慢一切的负担。