并行测试执行与 Flaky Test 治理：从变慢变脆到稳定高效

主因一：串行执行
  几百个测试一个接一个跑，90% 的时间浪费在等待

主因二：真实基础设施
  每个测试都连数据库/Redis/起服务 → 单测变集成测试

主因三：重复初始化
  每个测试都重建昂贵资源（Spring 上下文、docker、连接池）

变脆的主因：
  · 共享状态：测试之间通过静态变量/全局库互相污染
  · 时序依赖：依赖真实时间、真实端口、外部服务
  · 顺序依赖：测试 A 必须在测试 B 前跑（耦合顺序）

测试套件规模 100 个 → 串行 5 分钟 → 开发者勉强跑
测试套件规模 2000 个 → 串行 50 分钟 → 没人跑 → 回归裸奔
测试套件规模 10000 个 → 并行 + 分片 → 5 分钟 → 每次都跑

目标：套件 < 10 分钟，人人随时能跑

进程级并行（推荐首选）：
  · 每个 worker 独立进程 → 真隔离（内存、静态变量、全局）
  · 语言例子：pytest-xdist -n auto、JUnit 并行类级、Go 包级并行
  · 代价：进程开销略大、共享资源（DB）要分库/分 schema

线程级并行：
  · 同一进程内多线程 → 快，但共享状态容易炸
  · 只在"无共享、纯计算"的测试里用
  · 语言例子：JUnit 方法级并行、pytest 内部（不推荐）

# Python：pytest-xdist
pytest -n auto                          # CPU 核数 worker
pytest -n 8 --dist loadscope            # 按模块分布
pytest -n 4 --dist loadgroup            # 按自定义分组

# Java：JUnit 5 并行
# jUnit-platform.properties:
#   junit.parallel.enabled=true
#   junit.parallel.mode.classes.default=concurrent
#   junit.parallel.mode.default=concurrent

# Go：包级并行
go test -p 8 ./...                      # 并行编译+测试多个包
# Go 测试内 t.Parallel() 让同一包内的测试并行

并行暴露出来的问题，正是串行时被掩盖的问题：
  · 共享数据库 → 并发写冲突 → 必须先隔离数据
  · 共享端口 → 两个测试抢端口 → 动态端口分配
  · 共享静态变量 → 交叉污染 → 消除共享状态
  · 全局 Mock → 互相覆盖 → 每测试独立 setup

结论：并行不是"加个参数就快"，而是"倒逼测试真正隔离"

# conftest.py：每个 worker 拿到独立数据库 schema
def pytest_configure(config):
    worker = os.environ.get("PYTEST_XDIST_WORKER", "local")
    idx = worker.replace("gw", "") if worker != "local" else "0"
    os.environ["TEST_DB_NAME"] = f"test_{idx}"

MySQL/Postgres 并行测试：
  · 每 worker 建独立 schema，Fixture 里 drop/create
  · 或使用 Testcontainers：每 worker 一个容器（重但真隔离）
  · 事务回滚策略（@Transaction / rollback fixture）避免残留

func TestParallel(t *testing.T) {
    t.Parallel()
    // 必须：不共享包级变量、不共享同一文件句柄
    // 需要共享时用 sync 或每测试独立副本
}
// Go 测试设计上鼓励：测试之间零共享
// 真需要共享 → 用 TestMain 统一初始化只读资源

Flaky Test：同一份代码，时而通过时而失败，与代码本身无关
  典型信号：
    · 重跑就通过（retry 变绿）
    · 只在某台机器/某次并发下失败
    · 失败信息指向"超时/端口占用/顺序"而非业务断言

危害：
  · 测试不可信 → 团队开始 ignore 失败 → 真 bug 被漏掉
  · "重跑就绿" 成为惯例 → 质量门禁名存实亡

时序类（最常见）：
  · 竞态条件：异步任务未完成就断言（sleep 代替等待）
  · 超时太紧：CI 慢机器上超时 → 假失败

顺序/状态类：
  · 测试间隐式依赖顺序 → 并行/重排就炸
  · 共享状态残留：上一个测试留了脏数据

资源类：
  · 端口/连接池耗尽
  · 磁盘/内存压力

外部依赖类：
  · 真实网络调用（第三方 API 抖动）
  · 时间敏感（跨日/时区/闰秒）

随机类：
  · 未 seed 的随机数据 → 偶发边界

# 反复跑同一套件，暴露"偶发失败"
pytest --count=5 tests/flaky_suspect   # pytest-repeat

# 或 CI 专用 job：对可疑测试跑 N 次
go test -count=5 -run TestSuspect ./pkg

# 全量套件定期"乱序复跑"：
#   --dist=loadscope 与 --dist=loadgroup 交叉跑，暴露顺序依赖

Flaky 的处理纪律：
  1. 发现疑似 Flaky → 立刻标记（@flaky 注解/标签）
  2. 从门禁套件移到"quarantine 隔离区"（跑但不阻断发布）
  3. 记录复现率（10 次跑失败几次）
  4. 排期修复：隔离区不是垃圾桶，是"待修队列"
  5. 修复后观察一段时间（如 50 次全绿）再回门禁

禁止：对 Flaky 无脑加 retry 然后当作没事
  retry 是"止血"，不是"治疗"——必须同时记录根因

# 用 pytest 插件给可复现性打标的示例
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_third_party_sync():
    ...
# 记录：为什么 flaky？根因链接放到 issue 里

# Flaky 治理指标
flaky_test_count{suite}            # 隔离区数量
flaky_test_flake_rate{pct}          # 复现率（N 次跑失败比例）
flaky_test_quarantine_age_days      # 隔离区滞留时长（超 14 天报警）
flaky_test_retry_rate               # 依赖 retry 才能过的比例
flaky_new_total{week}               # 每周新增 Flaky
# 告警：新增 Flaky 上升 / 隔离区滞留超期

# ❌ 反模式：sleep 固定时间
time.sleep(5)
assert redis.get("key") == "done"    # 快机器过，慢机器挂

# ✅ 轮询等待条件（poll until）
def wait_until(cond, timeout=10, interval=0.1):
    deadline = time.time() + timeout
    while time.time() < deadline:
        if cond(): return
        time.sleep(interval)
    raise TimeoutError("condition not met")

def test_async_job():
    job.start()
    wait_until(lambda: repo.get(job.id).status == "DONE")
    assert repo.get(job.id).result == expected

# 注入时钟，禁止真实 now() 进业务逻辑
class OrderService:
    def __init__(self, clock): self.clock = clock

# 注入随机种子，让"随机"变"确定性"
random.seed(42)                        # 简单粗暴但有效
# 或用 property-based 的种子机制（hypothesis seed）

· 每个测试自包含：自己创建自己的数据，不依赖他人残留
· 测试结束清理：TearDown / fixture 自动清理（数据库 truncate）
· 不依赖"前面的测试执行过"（常见：signup 后才 login 的耦合）
· 用 fixture 而不是测试顺序传递状态

并行化 = 顺序依赖的照妖镜：
  若并行后失败，八成是"隐性顺序依赖"在作祟

目的：让 CI 总时间最短
  · 统计每个测试文件的历史耗时
  · 按耗时"拼图"分到各 shard（尽量均摊）
  · 工具：pytest-xdist --dist loadgroup 结合分组，
        或专门的分片工具（如 --shard-idx/--shard-count）
  · CI 里并行跑多个 shard，总时间 ≈ 最慢的 shard

· 编译缓存：Gradle/Go/Maven 增量编译（不变不重编）
· 依赖缓存：CI 层缓存（actions/cache、Docker build cache）
· 测试结果缓存：未变更的测试跳过（Gradle build cache、
  pytest-cache 的重跑跳过）
· 逻辑增量：按改动影响面选择测试子集（test selection）
  注意：增量选择要有"兜底全量"（定期全量防漏）

# GitHub Actions：分片并行
strategy:
  matrix:
    shard: [1, 2, 3, 4]               # 4 个 shard
steps:
  - run: |
      pytest -n auto --shard-idx=${{ matrix.shard }} \
            --shard-count=4 tests/
  # 缓存依赖加速
  - uses: actions/cache@v3
    with: { path: ~/.cache/pip, key: deps-${{ hashFiles('requirements.txt') }} }

规则一：Flaky 不阻塞门禁，但必须当天登记、限期修复
  隔离区不是免死金牌，滞留超期要升级

规则二：禁止无脑 retry
  加 retry 必须记录根因 issue，且统计 retry 率

规则三：测试代码也是代码
  测试要有评审：恶意共享状态、sleep、顺序依赖一票否决

规则四：确定性优先
  新测试要求：可重复、可并行、不依赖顺序
  门禁前 CI 做"乱序复跑"抽检

· "测试红了" 是重要信号，不是麻烦——要严肃对待
· 提交被 Flaky 拦截 → 先修根因再继续，别"跳过"
· 团队设立 Flaky 治理轮值（每周处理隔离区）
· 用数据说话：Flaky 数量、复现率、滞留天数进周报

□ 评估串行 vs 并行收益（先测各模块耗时）
□ 按资源类型隔离（DB/端口/文件/时钟/随机）
□ pytest -n auto / JUnit 并行 / Go -p 开启
□ 消除 sleep，改轮询等待条件
□ 注入时钟与随机种子，保证确定性
□ 每测试自包含、测试结束清理
□ Flaky 登记 + 隔离区 + 限期修复制度
□ 禁止无脑 retry（必须记录根因）
□ 按耗时分片 + 依赖缓存，控制 CI 总时长
□ 新测试确定性审查（顺序/共享状态一票否决）

"测试要么确定性通过，要么确定性失败——中间态的 Flaky 必须当天治理。"