Go testing/quick.Check 失败后怎样复现同一组输入

testing/quick.Check 的随机失败并不需要靠“再跑几次”碰运气。做法是把随机种子、迭代上限和失败输入一起记录下来；复现时用同一个 seed 新建一份 math/rand.Rand，并保持 quick.Config、Values 和自定义生成器不变。这样生成器会从同一个状态开始，失败样本就能重新出现。

官方地址：https://pkg.go.dev/testing/quick#Check

先把失败现场记录成三项数据

quick.Check 会反复调用一个返回 bool 的函数；一旦函数返回 false，它会返回 *quick.CheckError。这个错误的 In 是失败调用的参数列表，Count 是已经尝试到的次数。只打印 err.Error() 往往不够，因为下一次运行的随机序列可能已经改变。

排查记录至少应包含以下字段：随机种子 seed、实际使用的 MaxCount、失败位置 Count 和失败参数 In。其中 seed 负责重建输入序列，Count 与 In 用来确认复现的是同一个失败现场。

用固定 seed 注入 quick.Config.Rand

最小可复用写法是每次运行都通过 rand.New(rand.NewSource(seed)) 创建新的随机源，再把它交给 quick.Config.Rand。下面故意设置一个容易触发的属性，让重点落在复现机制，而不是业务算法。

package replay

import (
	"errors"
	"math/rand"
	"testing"
	"testing/quick"
)

func configFor(seed int64) *quick.Config {
	return &quick.Config{
		MaxCount: 200, // 固定尝试上限，避免复现时测试规模发生变化。
		Rand:     rand.New(rand.NewSource(seed)), // 每次从同一个 seed 建立独立随机源。
	}
}

func TestReplayableFailure(t *testing.T) {
	const seed int64 = 20261013
	cfg := configFor(seed)

	err := quick.Check(func(x int) bool {
		// 这里模拟一个对 7 的倍数处理不正确的属性，返回 false 即记录失败输入。
		return x%7 != 0
	}, cfg)
	if err == nil {
		return
	}

	var checkErr *quick.CheckError
	if errors.As(err, &checkErr) {
		// 同时输出 seed、Count 和 In，下一次才能按同一现场重跑。
		t.Logf("seed=%d count=%d inputs=%v", seed, checkErr.Count, checkErr.In)
		return
	}
	t.Fatal(err)
}

这里的关键不是把 seed 写死在测试代码里，而是让 seed 成为失败日志的一部分。生产测试可以从环境变量、命令行参数或 CI 产物中读取 seed，但传入 Config.Rand 的仍应是由它新建的随机源。

复现时要重新创建随机源

*rand.Rand 是有状态的。第一次运行已经从随机源取过一批数，如果直接把同一个对象交给第二次 quick.Check，它会从当前位置继续生成，虽然 seed 文本相同，实际序列却已经错开。复现函数应当每次都创建新配置和新随机源。

func runOnce(seed int64) (*quick.CheckError, error) {
	err := quick.Check(func(x int) bool {
		// 复现时属性函数本身也必须保持不变，否则同一输入没有可比性。
		return x%7 != 0
	}, configFor(seed))
	if err == nil {
		return nil, nil
	}

	var checkErr *quick.CheckError
	if errors.As(err, &checkErr) {
		return checkErr, nil
	}
	return nil, err
}

func TestSameInputSequence(t *testing.T) {
	const seed int64 = 20261013
	first, err := runOnce(seed) // 第一次运行从 seed 的初始状态开始。
	if err != nil {
		t.Fatal(err)
	}
	second, err := runOnce(seed) // 第二次重新建 Rand，避免复用已消费的状态。
	if err != nil {
		t.Fatal(err)
	}
	if first == nil || second == nil {
		t.Fatal("属性未失败，无法比较失败样本")
	}
	t.Logf("first count=%d inputs=%v", first.Count, first.In)
	t.Logf("second count=%d inputs=%v", second.Count, second.In)
}

在相同 Go 版本、相同属性函数和相同配置下，两次运行会从同一个伪随机状态开始。排查时可以把第一次日志中的 Count 和 In 与第二次日志对照：两个字段同时一致，才说明已经重现了同一个失败样本。

用一张小表确认复现是否对齐

指标驱动的排查不必复杂，先记录最小集合，再逐项比较。下表中的“示例记录”只是日志格式示意，实际 Count 和 In 以运行结果为准。

这些情况会让同一个 seed 也复现失败

复用了已经运行过的 Rand。先执行其他随机操作，再把同一个 *rand.Rand 放进 Config，输入序列已经前移。修复方式是每次复现都调用 rand.New，不要把可变的 Rand 作为多个测试共享状态。

自定义 Generator 消费方式变了。如果参数类型实现了 quick.Generator，Generate 方法会接收同一个随机源。Generator 内部多调用一次 Intn，后续所有参数的随机状态都会改变。因此要保留 Generator 的代码和字段顺序，不能只复制 seed。

Values 函数或 MaxCount 改了。Config.Values 会替代默认值生成逻辑；迭代上限也决定何时停止。复现阶段先冻结这些配置，定位完成后再单独做缩小输入或性能调整。

只保存了失败参数，没有保存 seed。直接把 In 手工传给业务函数可以验证一个样本，但它不能重跑整个随机序列，也无法确认失败是在第几次生成时出现。完整记录 seed、Count 和 In，才能同时支持定点验证与整体复盘。

CI 中建议保留的排查信息

随机属性测试失败时，日志至少打印 seed、MaxCount、Count、In，并记录提交版本或测试名称。修复后可以先用同一个 seed 做回归，再恢复默认随机源覆盖更多输入。不要在复现阶段偷偷换成另一个属性或第三方框架，否则即使测试通过，也不能证明原问题已经消失。

常见问题

只设置 seed 就一定能得到同一组输入吗？

不一定。还要保持 MaxCount、Values、自定义 Generator、属性函数和随机源的消费顺序一致。

为什么直接复用同一个 rand.Rand 会失败？

rand.Rand 内部状态会随着每次取数推进。复用对象等于从旧序列的中间位置开始，应该用同一个 seed 新建对象。

CheckError.In 能不能直接当成回归测试样本？

可以用于定点回归，但它只代表一次失败调用的参数。若还想复现随机序列和失败位置，应同时保存 seed 与 Count。