Go go test -shuffle 怎样复现随机测试顺序

Go 随机测试顺序出现失败后，保存日志中 -test.shuffle 后面的整数，再用 go test -shuffle=该整数 重跑原来的包和测试集合。继续用 on 会选择新的种子；只运行失败用例则可能移除触发它的其他用例。

我更倾向于把种子、代码提交和完整命令一起保存。种子是定位入口，测试是否相互独立才是最终要解决的问题。下面搭建一个只有两个测试的小项目。示例供读者自行执行，没有把预期现象当作本机实测记录。

Go 官方地址：https://go.dev/

建立一个只有两个测试的小项目

在独立目录中初始化模块，把下方 Go 代码保存为 state_test.go。项目不需要外部服务，故障只来自同一进程内的共享变量。

# 创建独立演示目录，避免把故障用例放入业务仓库
mkdir shuffle-demo
cd shuffle-demo
go mod init example.com/shuffle-demo

package shuffledemo

import "testing"

// 故意共享状态，暴露用例对执行顺序的依赖。
var activeMode = "normal"

func TestEnablePreview(t *testing.T) {
    activeMode = "preview"
    if activeMode != "preview" {
        t.Fatal("预览模式未启用")
    }
}

func TestDefaultMode(t *testing.T) {
    // 别的用例可能已经改变包初始化时的值。
    if activeMode != "normal" {
        t.Fatalf("默认模式应为 normal，实际为 %q", activeMode)
    }
}

TestEnablePreview 写入 preview，却没有恢复；TestDefaultMode 假定 activeMode 仍为 normal。前者先运行时，后者的断言会失败；反过来则可能通过。这里不调用 t.Parallel，便于把问题限定在用例的顺序依赖上。

记录发生失败的随机种子

# 显示用例名称，并显式要求实际执行测试
go test . -shuffle=on -count=1 -v

官方参数文档说明：on 使用系统时钟产生种子，整数参数使用指定种子，两种方式都会报告种子。日志中的 -test.shuffle 后面会跟一个整数。保存发生失败那一次的整数，不要把教程中的示意数字当成必然触发失败的种子。

这一轮若通过，可以重新启动同一条命令尝试另一种排列。两项测试的排列很少，下一次不保证与上一次不同，也不能承诺尝试固定次数后必定失败。完整保留包名、种子、用例名和断言信息，比只保存最后的 FAIL 更有用。

用固定种子保留原测试集合重放

# 数字只作示意，请替换成失败日志中的真实种子
go test . -shuffle=1700001234 -count=1 -v

在相同代码、工具链与测试集合下，固定种子用于重放随机排列。我会先完整回放，再尝试缩小范围。直接加 -run=TestDefaultMode 会跳过修改状态的测试，可能让问题暂时消失，不能据此认为已经修复。

原命令若有筛选条件，应先原样保留。多包执行时还要确认失败日志属于哪个包；各包有独立测试进程，不能把混合输出解释为统一的全局执行顺序。新增或删除顶层测试、修改工具链后，也不应假定同一整数仍对应原排列。

用独立实例消除共享状态

目标不是找到一个总能通过的种子，而是去掉隐含的初始化依赖。把 state_test.go 整体替换为下面的实现，让每个用例构造自己的状态：

package shuffledemo

import "testing"

type settings struct { mode string }

func newSettings() *settings {
    // 为每个用例创建独立状态。
    return &settings{mode: "normal"}
}

func TestEnablePreview(t *testing.T) {
    cfg := newSettings()
    cfg.mode = "preview"
    if cfg.mode != "preview" {
        t.Fatalf("预览模式错误：%q", cfg.mode)
    }
}

func TestDefaultMode(t *testing.T) {
    cfg := newSettings()
    // 断言自身的初始状态，不依赖其他测试先运行。
    if cfg.mode != "normal" {
        t.Fatalf("默认模式错误：%q", cfg.mode)
    }
}

多写一个构造函数，会让依赖更明确。实在无法去掉全局变量时，可以保存旧值并用 t.Cleanup 恢复；存在并行测试时，仅恢复旧值不能隔离并发读写。共享文件、数据库记录和外部缓存也应按用例划分资源，不能只修演示中的字符串。

把日志接入持续集成并判断结果

CI 可以继续使用随机探索，失败时把原种子与提交号写入工单。下面的 shell 片段保存所有输出，并在打印日志后返回原测试退出码，避免日志处理掩盖失败：

#!/bin/sh
# 失败时仍保存退出码，完整日志交给 CI 归档。
result=0
go test ./... -shuffle=on -count=1 -v >test-shuffle.log 2>&1 || result=$?
cat test-shuffle.log
exit "$result"

把 test-shuffle.log 配置成成功或失败都归档的产物，并记录 Go 版本、提交号和相关配置。归档入口依自己的 CI 设置。失败后另跑随机命令产生的新种子，不能覆盖原来的记录。

修改后先回放失败种子，再增加随机执行。成功应同时表现为断言成立、测试进程正常返回，并从代码上确认测试不再共享 activeMode；不能只看日志里有没有种子。

shuffle 会自动重排每个 t.Run 子测试吗？

不要这样理解。当前 testing 实现重排顶层测试与基准测试集合，子测试仍由父测试代码组织。表驱动数据若来自 map，遍历顺序还可能引入其他变化。

固定种子能复现 goroutine 调度吗？

不能。种子没有固定操作系统调度、网络返回和并行用例的交错。原问题若涉及并发，应保留原并发参数并分析同步与资源隔离，顶层排列相同不等于每个事件都相同。

直接关闭 shuffle 可以作为修复吗？

关闭它只会减少暴露问题的机会。对遗留测试，可以暂时保存固定种子作为定位入口，最终仍应让用例自己准备状态和清理资源。

参数语义见 Go 测试参数文档；顶层重排范围见 testing 官方实现。