Go 1.25 testing.Attr 实战：别让 CI 测试报告只剩一堆失败日志

很多团队的测试失败日志都有一个共同问题：它告诉你“失败了”，但没告诉你“这条失败到底属于哪个场景”。尤其是集成测试、表驱动测试、兼容性测试，一旦 CI 上刷出几百行日志，排查的人很容易迷路。

Go 1.25 在 testing 包里新增了两个我很喜欢的小能力：Attr 和 Output。它们不改变测试逻辑，却能让测试报告更像工程资产，而不是一坨临时日志。

这篇我按团队落地讲：什么时候用 T.Attr，什么时候用 T.Output，怎么配合 go test -json，以及怎么让 CI 报告更容易排障。

先说痛点：测试日志不是越多越好

以前我们写测试，常见做法是失败时一顿 t.Logf：

func TestRefund(t *testing.T) {
    t.Logf("env=%s", env)
    t.Logf("case=%s", "refund_timeout")
    t.Logf("order_id=%s", orderID)

    if err := runRefund(orderID); err != nil {
        t.Fatalf("refund failed: %v", err)
    }
}

这当然能用，但问题是所有信息都混在日志文本里。CI 平台想聚合“哪些用例属于支付场景”“哪些失败发生在灰度环境”“哪些 benchmark 属于数据库组”，就只能靠字符串解析。

Attr 的意义就在这里：把测试维度作为结构化元数据告诉测试框架。

Attr：给测试打上可聚合的标签

Go 1.25 给 testing.T、testing.B、testing.F 都提供了 Attr。它的使用方式很直接：

func TestRefund(t *testing.T) {
    t.Attr("domain", "payment")
    t.Attr("case", "refund_timeout")
    t.Attr("env", "staging")

    if err := runRefund(); err != nil {
        t.Fatalf("refund failed: %v", err)
    }
}

这些属性不会替代断言，也不是业务参数。它更像测试报告里的标签：告诉 CI 和排障的人，这个测试属于哪个维度。

我的建议是，Attr 的 key 要少而稳定，比如 domain、feature、case、env、priority。不要今天写 module，明天写 service，后天又写 biz，最后谁也聚合不了。

Output：比乱写标准输出更可控

另一个新增能力是 T.Output。它给当前测试返回一个输出 writer，让你把和这个测试相关的辅助信息写进去，而不是随手 fmt.Println 到全局标准输出。

func TestOrderFlow(t *testing.T) {
    out := t.Output()
    fmt.Fprintln(out, "step=create_order")
    fmt.Fprintln(out, "step=pay")

    if err := runOrderFlow(); err != nil {
        fmt.Fprintln(out, "failed_at=pay")
        t.Fatal(err)
    }
}

我喜欢它的地方是边界清楚：这是测试输出，不是业务日志，也不是进程级 stdout。以后 CI、IDE、测试报告工具要处理这些信息，会更容易。

但这里也要克制。Output 不是让你把所有调试日志都倒进去。只写能帮助定位失败的关键步骤，比如输入摘要、阶段名、外部依赖状态、关键 ID。

go test -json 才是它们的好搭档

如果你只在本地看纯文本输出，Attr 的价值会打折。它更适合配合：

go test -json ./...

JSON 输出能被 CI 系统、内部测试平台、报告生成器消费。测试属性、输出、失败事件如果都能被结构化采集，后面就可以做很多实用的事：

• 按业务域统计失败率。
• 按环境区分失败，比如 dev、staging、ci。
• 快速筛出 flaky 测试集中在哪个模块。
• 把失败上下文展示在 PR 评论里。

这比在日志里搜关键词舒服得多。

表驱动测试怎么用

表驱动测试里，我会把 Attr 放在每个子测试里，而不是只放在外层。

func TestDiscount(t *testing.T) {
    cases := []struct {
        name     string
        scene    string
        priority string
    }{
        {"vip", "member", "P1"},
        {"coupon", "promotion", "P2"},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Attr("scene", tc.scene)
            t.Attr("priority", tc.priority)
            assertDiscount(t, tc)
        })
    }
}

这样 CI 看到的是每个子测试的属性，而不是一个大测试的笼统标签。排查 flaky 用例时尤其有用。

Benchmark 也可以打标签

B.Attr 对性能测试也有价值。比如同一个 benchmark，你可以标记数据规模、依赖类型、是否走缓存。

func BenchmarkEncodeOrder(b *testing.B) {
    b.Attr("component", "json")
    b.Attr("payload", "order")
    b.Attr("size", "small")

    for b.Loop() {
        _ = encodeOrder(sampleOrder)
    }
}

当 benchmark 结果被平台收集后，这些标签可以帮助你按组件看性能趋势，而不是只盯着函数名。

团队规范怎么定

我建议先不要搞太复杂。团队可以先固定 5 个以内的 key：

• domain：业务域，比如 payment、order、user。
• component：技术组件，比如 mysql、redis、json。
• case：关键场景，比如 timeout、retry、empty_input。
• env：执行环境，比如 ci、staging。
• priority：测试优先级，比如 P0、P1、P2。

少比多好。字段太多，最后大家会乱填；字段稳定，CI 才能聚合。

不要拿 Attr 塞敏感信息

Attr 会进入测试输出或报告链路，所以不要把 token、手机号、订单真实金额、用户隐私信息塞进去。它应该放分类信息，不应该放敏感数据。

如果确实需要定位某个测试输入，用脱敏 ID 或 hash。测试报告通常会被更多人看到，别把它变成新的泄露入口。

我的 review 清单

• 关键集成测试是否有稳定的 domain、case 或 component 属性。
• 表驱动子测试是否在子测试内部写 Attr。
• Output 是否只输出失败定位需要的关键信息。
• CI 是否使用 go test -json 并消费结构化结果。
• Attr key 是否有团队规范，避免随意发明字段。
• 测试元数据里是否避免敏感信息。

最后说句实在话

Attr 和 Output 都不是让测试“更会跑”的能力，而是让测试“更会说话”。测试失败不可怕，可怕的是失败以后没人能快速看懂它属于什么场景、为什么失败、下一步该找谁。

如果你们 CI 里已经有不少集成测试和 benchmark，我建议从最痛的几个模块开始试。先固定少量 Attr key，再把 go test -json 接到报告里。一个月后你会发现，排查测试失败这件事会安静很多。