Go test -json 输出如何按 Action 还原测试事件

很多 CI 工具执行 go test -json ./... 后，第一反应是读取每行 JSON，再看到 Action=output 就当成一条结果。这样做很快会遇到两个问题：并行测试的事件会交错，日志也会被拆成多条。正确做法是把它看成一个按顺序到达的事件流：用 Package 和 Test 定位对象，用 Action 更新状态，再把同一对象的 Output 拼起来。

先把 go test -json 看成 TestEvent 流

Go 官方的 test2json 将测试输出编码为换行分隔的 JSON。每一行对应一个事件，常见字段包括 Time、Action、Package、Test、Elapsed 和 Output。流通常从 start 开始；真正判断结果时，应关注终态 Action，而不是输出文本中的“PASS”字样。

用 Package 加 Test 还原并行事件

当测试调用了 t.Parallel()，事件顺序不再是“一个测试完整结束后才开始下一个”。同一条流里可能先后出现不同测试的 run、output 和 pass。因此建议使用 Package + "\x00" + Test 作为测试级复合键，使用空字符串 Test 的另一条记录保存包级信息。

不要为了排序而按测试名重新排列事件。保留读取顺序，日志才能与 Action 对齐；需要展示时，再按复合键输出聚合后的摘要。

按 Action 更新状态，不要把 output 当结果

最小解析器可以只保留每个对象的当前状态、耗时和输出缓冲。下面的示例故意不运行测试，也不假设事件一定连续；它展示的是消费边界：

type TestEvent struct {
    Package string  `json:"Package"`
    Test    string  `json:"Test"`
    Action  string  `json:"Action"`
    Elapsed float64 `json:"Elapsed"`
    Output  string  `json:"Output"`
}

type Result struct {
    State   string
    Elapsed float64
    Output  strings.Builder
}

func consume(r io.Reader) (map[string]*Result, error) {
    results := make(map[string]*Result)
    scanner := bufio.NewScanner(r)
    // 测试日志可能很长，扩大单行 JSON 的读取上限。
    scanner.Buffer(make([]byte, 4096), 1024*1024)

    for scanner.Scan() {
        var event TestEvent
        if err := json.Unmarshal(scanner.Bytes(), &event); err != nil {
            return nil, err // 坏行要交给上层决定是否终止流水线
        }
        key := event.Package + "\x00" + event.Test
        item := results[key]
        if item == nil {
            item = &Result{}
            results[key] = item
        }
        if event.Action == "output" {
            item.Output.WriteString(event.Output) // 多条 output 必须按到达顺序拼接
            continue
        }
        switch event.Action {
        case "run", "pause", "cont", "pass", "fail", "skip", "bench":
            item.State = event.Action
            item.Elapsed = event.Elapsed
        }
    }
    return results, scanner.Err()
}

这里的关键点有三个：output 只写入缓冲区；Elapsed 主要在终态事件上有意义；包级事件因为 Test 为空，必须允许单独存在。若只关心最终结果，可以在输出摘要时过滤 start、run、pause 和 cont。

包级结果、构建失败和缓存要单独处理

一个测试包会有一组 Test 非空的事件，最后还会有 Test 为空的包级事件。包级 fail 不一定意味着某个测试函数返回失败，也可能是编译失败；官方事件在这种情况下可能提供 FailedBuild，解析器应把它展示成“包构建失败”，不要虚构一个测试名。

另外，缓存结果可能没有时间戳。时间字段为空并不等于事件无效，最终状态仍以 Action 为准。benchmark 也有特殊性：计时结果常以没有 Test 的 output 出现，benchmark 自身的日志和最终 bench 事件则可能带有 Test 名称。

落地前的四项检查

• key 是否同时包含 Package 和 Test，是否保留了 Test 为空的包级记录？
• 是否把同一对象的多条 Output 原样按顺序拼接，而不是覆盖旧日志？
• 是否将 pause、cont 当作运行状态，而不是失败状态？
• 是否能区分普通测试失败、包构建失败、skip 和 benchmark 收口？

常见问题

为什么不能只读取最后一个 JSON 事件？

最后一个事件通常是包级收口，不能替代每个测试的结果；并行执行时还可能需要保留中间日志和子测试状态。

Output 事件可以直接解析成失败信息吗？

不可以。Output 只是标准输出或标准错误的一段内容，失败应由对应对象的 fail Action 确认。

Test 为空是不是说明没有运行测试？

不一定。Test 为空也可能是包级 start、pass、fail、skip，或 benchmark 的包级输出，需要结合 Package 和 Action 判断。

把 go test -json 当成事件流后，解析逻辑就会从“猜日志”变成“维护状态”：先按 Package 和 Test 分流，再按 Action 更新，最后用包级事件收口。这个模型既适合 CI 摘要，也适合把测试结果送进消息队列或质量看板。