Go test -json 输出怎样按事件解析

如果你把 go test -json ./... 的结果当成一个 JSON 数组来解析，第一步就会走偏。它实际输出的是连续的 JSON 对象，每个对象占一条记录；记录之间可能交错出现，解析器要靠 Action、Package 和 Test 还原事件含义。

最稳妥的做法是用 json.Decoder 持续读取对象，先按 Action 分流，再用 Package 和 Test 作为归并键拼接 Output。不要等待完整输出后再按字符串猜测状态。

官方资料：https://pkg.go.dev/cmd/go　https://go.dev/src/cmd/test2json/main.go

一、-json 到底输出了什么

go test -json 的目标是让测试输出适合自动化处理。它输出换行分隔的 JSON 对象流，而不是带首尾方括号的数组，所以接收端可以边运行边消费，适合 CI 日志、测试看板和失败摘要。

单包测试事件通常可以看作 TestEvent：Action 表示状态变化，Package 表示包，Test 在事件针对某个测试函数时出现，Elapsed 出现在通过或失败事件中，Output 承载测试输出。多包运行时，不同包的记录会交错，不能用“读到某个包的 pass 后就结束”这种全局判断。

二、先按 Action 区分事件类型

事件解析的核心不是先解析一大段文本，而是先看 Action。测试生命周期常见值包括 start、run、pause、cont、pass、fail、output 和 skip；基准测试还可能看到 bench。

同一条 -json 流还可能带有构建事件，例如 build-output 和 build-fail。构建事件使用 ImportPath 标识构建中的包，这个值不应和测试事件的 Package 混为一谈。若失败事件带有 FailedBuild，还应把它作为构建失败处理，而不是误报成测试函数断言失败。

三、用 Decoder 逐个读取 JSON 对象

读取端可以直接消费标准输入。json.Decoder.Decode 会从流中读取下一个 JSON 值，因此不需要先把所有行收集到内存里；遇到 io.EOF 才代表流正常结束。

package main

import (
	"encoding/json"
	"fmt"
	"io"
	"os"
)

// Event 同时保留测试事件和构建事件需要的字段。
type Event struct {
	Time        string  `json:"Time"`
	Action      string  `json:"Action"`
	Package     string  `json:"Package"`
	Test        string  `json:"Test"`
	Elapsed     float64 `json:"Elapsed"`
	Output      string  `json:"Output"`
	OutputType  string  `json:"OutputType"`
	FailedBuild string  `json:"FailedBuild"`
	ImportPath  string  `json:"ImportPath"`
}

func main() {
	decoder := json.NewDecoder(os.Stdin)
	for {
		var event Event
		if err := decoder.Decode(&event); err != nil {
			if err == io.EOF {
				// 输入流正常结束，不把 EOF 当成解析失败。
				return
			}
			// 单条 JSON 损坏时停止，避免继续输出不可信状态。
			fmt.Fprintf(os.Stderr, "decode event: %v\\n", err)
			os.Exit(1)
		}

		// Action 是第一层路由键，不能只根据是否有 Test 字段猜类型。
		switch event.Action {
		case "start", "run", "pause", "cont", "pass", "fail", "skip", "bench":
			fmt.Printf("test package=%s test=%s action=%s elapsed=%.3fs\\n",
				event.Package, event.Test, event.Action, event.Elapsed)
		case "output":
			// Output 可能被拆成多条事件，消费端应按到达顺序保存。
			fmt.Printf("output package=%s test=%s type=%s %q\\n",
				event.Package, event.Test, event.OutputType, event.Output)
		case "build-output", "build-fail":
			// 构建事件的包标识在 ImportPath，不要拿 Package 代替。
			fmt.Printf("build import=%s action=%s %q\\n",
				event.ImportPath, event.Action, event.Output)
		default:
			// 保留未知 Action，便于工具链增加事件时观察变化。
			fmt.Printf("unknown action=%s package=%s\\n", event.Action, event.Package)
		}
	}
}

这个结构有两个实际好处：解码和处理可以同时进行，且多包并行时不会因为事件交错而破坏输入顺序。生产环境可以把 fmt.Printf 换成消息投递或状态存储，但路由字段不应改变。

四、Output 不能只保留最后一条

Action == "output" 时，Output 只是完整输出的一段。工具链可能拆成多个事件，同一个测试也可能先后产生框架行、普通日志和错误行。若只保存最后一条，失败原因经常会被截断。

归并键可以采用“包 + 测试名”。包级事件的 Test 为空，要和具体测试函数分开存储；当多个包同时执行时，Package 是区分交错输出的必要字段。

type OutputKey struct {
	Package string
	Test    string
}

type Collector struct {
	Text map[OutputKey]string
}

func (c *Collector) Add(event Event) {
	if event.Action != "output" {
		return
	}
	// 使用字符串追加保持事件到达顺序，适合生成失败摘要。
	key := OutputKey{Package: event.Package, Test: event.Test}
	c.Text[key] += event.Output
}

// Summary 在 pass/fail/skip 到达后读取对应键，避免提前总结。
func (c *Collector) Summary(event Event) string {
	key := OutputKey{Package: event.Package, Test: event.Test}
	return c.Text[key]
}

如果需要持久化，可以在收到 pass、fail 或 skip 后提交这个键的内容；不要把每一条 output 都当成最终结论。对于基准测试，最终动作可能是 bench，但其输出同样要按事件顺序保存。

五、兼容构建失败、缓存和 stderr

一套可用的解析器还要处理三个边界：

• 缓存结果通常缺少实际运行时间，不能用 Time 或 Elapsed 是否存在来判断成功，状态应以 Action 为准。
• 构建失败可能没有进入测试函数阶段，看到 build-fail 或带 FailedBuild 的 fail 时，应输出“构建失败”路径。
• 即使启用 -json，早期严重错误仍可能从标准错误输出非 JSON 文本，管道程序应单独保留 stderr。

例如在 CI 中，可以把标准输出交给事件解析器，把标准错误写入独立日志：

# 标准输出交给逐事件解析器，标准错误保留为构建诊断日志。
go test -json ./... 2>build-error.log | go run ./cmd/parse-test-json

不要为了“统一格式”把 stderr 强行包成测试事件；它可能是 go 命令在生成 JSON 事件前报告的启动、构建或环境问题。解析器应该让这条信息和事件流一起进入最终报告，但保留来源区分。

六、最小速查表与适用边界

这套方法适合消费 go test -json 的实时结果：先逐对象读取，再按 Action 分流，最后按包和测试归并。只有在你需要把单独构建好的测试二进制输出转换成 JSON 时，才考虑 go tool test2json；多包命令仍应优先使用 go test -json。

常见问题

为什么不能用 bufio.Scanner 直接按默认配置读很长的输出？

Scanner 有单 token 大小限制，超长单行 JSON 可能触发扫描错误。要按行读取时应显式调整 buffer，或者像本文一样使用 json.Decoder 逐对象解码。

Package 为空时是不是解析错了？

不一定。字段可能在某些非测试或异常事件中缺失；不要把空字段直接当成失败，应结合 Action、ImportPath 和 FailedBuild 一起判断。

为什么结果里看不到每个测试函数的完整输出？

因为 Output 是分片事件，而且包级输出的 Test 可能为空。必须用 Package 和 Test 组成键并持续追加，等 pass、fail、skip 或 bench 事件到达后再生成摘要。