测试策略与质量保障：从测试金字塔到 CI 门禁

风险对齐模型：
风险 = 影响面 × 出错概率 × 难以恢复程度

高风险（必须重测）：
□ 时间线排序与 Fanout（错了全站用户看到错误内容）
□ 鉴权与会话（错了 = 安全事件）
□ 计数与结算（错了 = 数据不一致 + 资金风险）

低风险（轻量覆盖）：
□ 纯展示文案、样式调整
□ 内部后台的只读页面

策略推论：
□ 高风险路径：多层覆盖（单元 + 集成 + E2E）
□ 低风险路径：单元测试或人工验收即可
□ 不为「覆盖率数字」写无意义测试

              ▲  E2E（少而精）
             ╱ ╲   完整用户流程，跨服务
            ╱───╲
           ╱     ╲  集成 / 组件（中量）
          ╱───────╲  模块协作、数据库、HTTP 边界
         ╱         ╲
        ╱───────────╲ 单元测试（大量）
       ╱             ╲ 纯函数、纯逻辑，毫秒级
      ╱───────────────╲

// 单元测试：表驱动，覆盖边界，零依赖，毫秒级
func TestHotScore(t *testing.T) {
    cases := []struct {
        name     string
        likes    int
        comments int
        ageHours float64
        want     float64
    }{
        {"新鲜热门", 100, 20, 1, 0},
        {"旧内容衰减", 100, 20, 72, 0},
        {"零互动", 0, 0, 1, 0},
    }
    for _, c := range cases {
        t.Run(c.name, func(t *testing.T) {
            got := HotScore(c.likes, c.comments, c.ageHours)
            // 边界断言：旧内容分数必须低于新内容
            if c.ageHours > 24 && got >= HotScore(c.likes, c.comments, 1) {
                t.Fatalf("衰减失效: %v", got)
            }
        })
    }
}

// 集成测试：testcontainers 起真实 PostgreSQL
func TestTimelineRepository(t *testing.T) {
    ctx := context.Background()
    pg, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
        ContainerRequest: testcontainers.ContainerRequest{
            Image:        "postgres:16-alpine",
            ExposedPorts: []string{"5432/tcp"},
            Env: map[string]string{
                "POSTGRES_PASSWORD": "test",
                "POSTGRES_DB":       "miniblog_test",
            },
            WaitingFor: wait.ForListeningPort("5432/tcp"),
        },
        Started: true,
    })
    if err != nil { t.Fatal(err) }
    defer pg.Terminate(ctx)

    dsn := buildDSN(t, pg)
    repo := NewTimelineRepo(dsn)
    // 每个用例独立事务，结束回滚，保证隔离
    seedFollows(t, repo, "alice", "bob")
    got, err := repo.PullTimeline(ctx, "alice", 20)
    require.NoError(t, err)
    require.Len(t, got, 1)
}

// HTTP 边界用 httptest，验证状态码、字段与错误语义
func TestCreatePostHandler(t *testing.T) {
    srv := httptest.NewServer(NewRouter(fakeRepo))
    defer srv.Close()
    resp, _ := http.Post(srv.URL+"/api/posts", "application/json",
        strings.NewReader(`{"text":"hello"}`))
    if resp.StatusCode != http.StatusCreated {
        t.Fatalf("want 201, got %d", resp.StatusCode)
    }
}

前端测试分层：
□ 组件测试（Vitest + Testing Library）：以用户视角断言
  · 「点击发布 → 调用 onSubmit 且禁用按钮」
  · 查 DOM 用 role/label，而非 class（更贴近无障碍语义）
□ E2E（Playwright）：跨浏览器跑关键流程

组件测试的反模式：
□ 断言内部 state / 实现细节 → 重构就挂
□ 用 querySelector('.btn-primary') → 改样式就挂
□ 什么都 mock → 测的是 mock 不是组件

// Playwright：只跑核心旅程，跑得快、失败可定位
test('用户可以完成一次发帖并看到自己的帖子', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('用户名').fill('alice');
  await page.getByLabel('密码').fill(process.env.TEST_PW!);
  await page.getByRole('button', { name: '登录' }).click();

  await page.getByRole('textbox', { name: '写点什么' }).fill('Hello miniblog');
  await page.getByRole('button', { name: '发布' }).click();

  await expect(page.getByText('Hello miniblog')).toBeVisible();
});

契约测试（Contract Testing）解决什么：
□ 消费者（前端/下游服务）声明「我需要什么字段」
□ 提供者（API 服务）声明「我提供什么字段」
□ 两者不一致 → CI 立即失败，而不是等集成时才炸

流程：
1. 消费者测试生成契约（pact/OpenAPI 片段）
2. 契约上传到 Broker
3. 提供者 CI 验证自己满足所有契约
4. 任一不满足 → 阻止发布

测试数据三原则：
□ 可重复：每次运行从已知状态出发（工厂 + 随机唯一键）
□ 隔离：用例之间不共享可变数据（独立事务/独立 schema）

工厂模式（Factory）：
□ 生成最小可用的实体：makeUser()、makePost()、makeFollow()
□ 关键字段可覆盖：makePost({ visibility: "private" })
□ 唯一键用随机后缀，避免唯一约束冲突

Flaky 的常见根因：
□ 时间依赖：依赖真实时钟、跨时区、依赖执行顺序
□ 并发竞态：共享状态、并行用例互相踩
□ 异步等待：sleep 固定时长而非等待条件
□ 外部依赖：真实第三方 API 抖动
□ 数据污染：用例间共享可变数据
□ 资源竞争：端口、临时文件、容器名冲突

治理手段：
□ 等待条件而非 sleep：await expect(...).toBeVisible()
□ 注入可控时钟：不要用 time.Now() 断言
□ 用例隔离：每个用例独立事务 / 独立命名空间
□ 固定随机种子：可复现
□ 依赖替身：第三方走 mock，去掉网络抖动

1. 检测：CI 重跑失败用例，记录「首次失败但重跑通过」的用例
2. 隔离：确认 flaky 的用例打 quarantine 标记，从阻塞门禁中移出
3. 修复：限期修复（如 7 天），到期未修则删除
4. 度量：把 flaky 率作为质量指标，纳入看板

性能测试类型：
□ 基准测试（Benchmark）：单函数/单接口的耗时基线
□ 负载测试（Load）：预期峰值下的稳定性
□ 压力测试（Stress）：逐步加压找拐点

Go 基准：
  go test -bench=BenchmarkTimeline -benchmem -count=10
  关注 ns/op、B/op、allocs/op，并做前后对比

func BenchmarkTimelineRender(b *testing.B) {
    feed := seedFeed(100)
    b.ReportAllocs()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = RenderTimeline(feed)
    }
}

覆盖率的正确用法：
□ 看「未覆盖的高风险代码」而非「总百分比」
□ 设地板而非天花板：新增代码覆盖率 ≥ 80%
□ 覆盖率下降要解释：新代码没测试还是删了测试

无效覆盖率的反模式：
□ 为凑数字写「调用即断言」的空测试
□ 全局 100% 目标 → 逼出大量无价值测试
□ 用覆盖率当 KPI → 团队刷数字

# CI 门禁示例：分层且可诊断
stages: [lint, unit, integration, e2e]
lint:
  script: [golangci-lint run, npm run typecheck]
unit:
  script: [go test -race -coverprofile=cov.out ./...]
  coverage: '/total:\s+\(statements\)\s+(\d+\.\d+)%/'
integration:
  script: [go test -tags=integration ./...]
e2e:
  script: [npx playwright test]
  artifacts: [trace.zip, screenshots/]