Gotestsum CI 测试失败摘要器

你要解决的具体问题

CI 里一次 go test ./... 跑完整仓，失败时打印出来的往往是几十屏原始输出：同一次运行里既有第一个失败的 panic 栈，也有后面一连串因为共享状态被污染而跟着挂掉的测试。修复循环里的 Agent 直接读这份日志，很容易把注意力浪费在「第二次、第三次失败」上，去改一个其实只是被上游失败带崩的用例，而不是真正的根因。

另一个常见问题是抖动测试（flaky test）。有些用例只在资源紧张、并发调度不稳定时偶发失败，CI 上重跑一次就过了。但这类失败同样会触发一次完整的修复循环，成本却完全不对等。

技能如何工作

它把工作分成两层：先结构化总结，再重跑验证。

• 底层执行的是 go test -json，技能通过 gotestsum 把这份流式 JSON 解析后重新排版，输出格式化的测试结果和一份运行摘要，而不是把原始日志原样吐出来。
• 失败信息被压缩成紧凑的摘要，失败的测试名和失败阶段一目了然。同时可以选择产出 JUnit 或 JSON 工件，方便流水线归档，也能和上一次运行做对比。
• 在把这些结果交给修复循环之前，可以先对失败用例做一轮 重跑。如果某个测试在重跑中稳定通过，它就是抖动，不该占用修复预算；只有重跑仍然失败的用例，才值得进入真正的排查。

整体思路是：把「这次运行失败了什么」和「这次运行为什么会失败」分开处理，让修复动作只落在稳定的失败上。

适用边界与注意点

• 重跑失败用例依赖 --rerun-fails 一类开关，不同环境可能要再配合其他参数。上游在 moby（即 Docker）相关场景下就提示过这一点。
• 输出里的图标依赖 Nerd Fonts 字体，终端没装对应字体时摘要中的图标会显示成方块，但不影响文本内容本身。
• 技能处理的是测试运行的呈现与重试决策，它不负责修代码。重跑之后仍然失败的部分，依旧要靠人读栈、定位竞态或共享状态问题。
• 如果某个失败是真正的确定性回归，重跑只会多花掉几轮时间，不会自动消失。需要留意重跑次数上限，避免 CI 时长被无意义的重试拉长。