Go testing.Short 怎样让慢测试只在完整模式运行

Go 测试套件一旦加入真实文件、外部服务或较重的初始化，开发者通常希望本地改一行代码时先得到快速反馈，合并前再跑完整覆盖。这个需求不必再维护一套平行测试入口：可以让测试代码读取 testing.Short()，在短模式下用 t.Skip 跳过明确标记为昂贵的测试。

官方参考：https://pkg.go.dev/testing#Short

核心做法是：快速单元测试保持默认运行；只有确实依赖外部资源或成本较高的测试，在 testing.Short() 为真时跳过。-short 只是测试运行标志，不会自动识别哪些测试“应该慢”。

先弄清 -short 与 testing.Short 的关系

go test -short 会让测试二进制带上 -test.short 标志，testing.Short() 负责报告这个标志当前是否开启。它本身不跳过任何函数，也不改变测试并发度；跳过动作要由测试代码显式调用 t.Skip、t.Skipf 或 t.SkipNow。

快速试用：让昂贵测试只在完整模式运行

把判断放在昂贵准备动作之前。这样短模式不会先连接外部服务再跳过，完整模式也仍然使用同一份测试逻辑。

func TestImportFromService(t *testing.T) {
	// 短模式只保留快速反馈，避免建立真实外部依赖。
	if testing.Short() {
		t.Skip("跳过外部服务测试：请使用完整模式运行")
	}

	// 只有完整模式才准备昂贵的测试夹具。
	fixture, err := newServiceFixture()
	if err != nil {
		t.Fatalf("准备测试夹具失败: %v", err)
	}
	// 测试结束时释放外部资源，避免影响后续测试。
	t.Cleanup(func() { fixture.Close() })

	if err := runImport(fixture); err != nil {
		t.Fatalf("导入失败: %v", err)
	}
}

这段代码的关键不在于字符串内容，而在于判断位置：testing.Short() 放在创建夹具之前，短模式就不会承担连接、迁移或大文件准备成本。t.Skip 表示当前测试被有意跳过，不应被当作失败处理。

用命令区分快速反馈和完整覆盖

本地开发可以把 -short 作为明确意图写进命令或脚本；需要覆盖昂贵测试时省略它。命令行示例：

# 本地快速检查：跳过代码中主动标记的昂贵测试。
go test -short ./...

# 合并前完整检查：不设置 -short，执行完整测试集合。
go test ./...

不要把两条命令理解成两套不同的测试。它们选择的是同一套测试代码的不同运行模式，差别由测试内部的边界判断决定。测试报告中出现 skip 时，应回到测试名和跳过原因确认它是否正是预期的昂贵部分。

把测试分层，而不是到处复制判断

一个可维护的分层方式是：默认单元测试不依赖 -short，始终提供稳定反馈；外部服务、真实网络、迁移或大数据准备集中在少数测试入口，由入口统一判断短模式；测试夹具和项目自定义开关负责表达更具体的环境要求。

如果一个测试函数里有多段成本不同的准备工作，可以拆成子测试或辅助函数，让“是否需要完整模式”的判断靠近那段成本最高的边界。不要在每个断言前都调用一次 testing.Short()，否则测试的真正意图会被分散。

与自定义环境变量相比，怎么选

testing.Short() 适合表达整个测试运行的“快速/完整”意图，优点是调用方式统一、能直接配合 go test -short。但它的语义很窄：它只告诉你短标志是否开启。

如果项目还需要区分数据库地址、凭据、区域或模拟服务，应继续使用项目自己的配置入口。例如，环境变量可以决定连接到哪个测试服务，而 testing.Short() 只决定是否跳过这类测试。不要把凭据是否存在、网络是否可达等环境问题混成短模式判断。

func TestWithConfiguredEndpoint(t *testing.T) {
	// 短模式直接跳过外部依赖，完整模式再读取项目配置。
	if testing.Short() {
		t.Skip("短模式不连接外部端点")
	}

	endpoint := os.Getenv("TEST_ENDPOINT")
	if endpoint == "" {
		t.Fatal("完整模式需要设置 TEST_ENDPOINT")
	}
	// 将配置校验放在完整模式入口，错误信息更接近真正的缺失原因。
	if err := checkEndpoint(endpoint); err != nil {
		t.Fatalf("测试端点不可用: %v", err)
	}
}

这里的职责分工是：短标志控制是否进入外部测试，项目配置控制进入后连接什么对象。两者可以同时存在，但不要用一个开关承担所有环境决策。

采用前要记住的边界

• 它不是并发控制。 -short 不会替你解决共享变量或并行子测试隔离问题。
• 它不是缓存清理。 测试缓存是否命中由 go test 的缓存规则决定，不能用短模式推断代码一定重新执行。
• 它不是安全隔离。 短模式只是应用层的测试选择，不能当作凭据保护、网络隔离或数据清理机制。
• 跳过条件要可解释。 用具体原因说明跳过了哪个外部依赖，避免 CI 里出现无法判断的“绿色”。

相关问题

不传 -short 时 testing.Short 返回什么？

通常返回 false，测试代码不会因为调用了 testing.Short() 就自动跳过。是否执行完整测试，仍取决于代码是否把该结果交给了 t.Skip。

能不能用环境变量完全替代 -short？

可以做项目级补充，但不建议把所有测试运行意图都藏在环境变量里。标准的 go test -short 更容易被开发者和 CI 读懂，自定义变量则适合表达服务地址、凭据和部署环境。

慢测试应该放在单独的测试包吗？

如果依赖、权限或准备流程已经明显不同，拆包或拆测试目标可能更清晰；如果只是同一套代码中的少量昂贵用例，用 testing.Short() 和明确的跳过原因就足够。

总结一下：把 testing.Short() 看成“当前是否要求快速测试”的读取接口，把 t.Skip 看成测试代码自己的选择动作。快速单元测试默认运行，昂贵测试在准备资源前短路，项目配置继续承担环境细节，这样本地反馈和完整覆盖就能共存。