解析Golang中的Skip与Short测试模式 Go语言灵活控制测试执行

go test -short 仅当测试函数中调用 testing.short() 并配合 t.skip() 时才跳过耗时测试，否则无效；它不影响 benchmark 和 example，且不自动传递至子包。

Go test -short 是怎么跳过耗时测试的

它不是靠注释或特殊标记识别，而是依赖 testing.Short() 函数返回布尔值，由你主动判断是否跳过。没调用这个函数，-short 就完全不起作用。

常见错误是写完 go test -short 发现所有测试照常跑——因为测试函数里根本没查 testing.Short()。

• 必须在测试函数开头显式调用 t.Skip("skipping in short mode") 配合 testing.Short() 判断
• -short 只影响当前包，子包不会自动继承（比如 go test ./... -short 会逐个包检查）
• CI 环境常用 GOFLAGS="-short" 全局启用，但本地开发建议显式加参数，避免误判

func TestExpensiveDBQuery(t *testing.T) {     if testing.Short() {         t.Skip("skipping DB test in short mode")     }     // 实际耗时逻辑... }

testing.T.Skip() 和 testing.T.SkipNow() 有什么区别

二者都终止当前测试，但触发时机和语义不同：Skip() 是“计划跳过”，会先记录跳过原因；SkipNow() 是“立刻退出”，不带说明，也不走 defer 清理逻辑。

容易踩的坑是误用 SkipNow() 在 setup 后、断言前——它会绕过后续所有代码，包括本该执行的 defer 资源释放。

立即学习“go语言免费学习笔记（深入）”；

• t.Skip("reason")：推荐用于条件性跳过，支持格式化字符串，会输出跳过日志
• t.SkipNow()：极少需要，仅适合极早期拦截（比如检测环境变量缺失），且无须日志
• 两者都不会标记测试失败，状态显示为 SKIP，不影响整体 exit code

为什么 t.Skip() 在 TestMain 里不生效

因为 TestMain 是测试启动入口，不是单个测试函数，t.Skip() 的接收者 t 在这里根本不存在。

想全局控制测试跳过，只能靠外部条件（如环境变量、命令行标志）配合 os.Exit(0) 提前退出，或者在每个 TestXxx 里分别判断。

• TestMain(m *testing.M) 中不能调用任何 t. 方法，否则编译报错
• 若需统一跳过整包测试，可用 os.Getenv("SKIP_TESTS") != "" + os.Exit(0)，但会丢失 skip 日志
• 更稳妥的做法仍是把跳过逻辑下沉到每个测试函数，保持可观察性

短测试模式下，Benchmark 和 Example 会被跳过吗

不会。go test -short 只影响 TestXxx 函数，对 BenchmarkXxx 和 ExampleXxx 完全无感。

这意味着你在 CI 里加了 -short，却忘了单独禁用 benchmark，可能导致超时失败——尤其当 benchmark 本身含 I/O 或 sleep 时。

• 显式禁用 benchmark：加 -bench=^$（空正则）
• Example 默认不运行，除非加 -run=Example 或 -example，所以不受 -short 影响
• 如果 benchmark 里也用了 testing.Short()，那是你手动加的逻辑，不是框架行为

真正容易被忽略的是：Skip 和 Short 是协作关系，不是开关关系。没有 testing.Short() 的判断，t.Skip() 就只是普通跳过；而没配 t.Skip()，-short 就只是个摆设。两头都得动手，少一个环节就失效。