Go testing.T Skip 怎样保留条件不满足的测试原因

测试不是只有“通过”或“失败”两种情况：某个外部服务没有启动、运行在短测试模式、测试数据不适用时，继续断言反而会制造误报。Go 的 testing.T.Skip、SkipNow 和 Skipf 就是为这种运行时条件准备的。关键是把“暂时不具备测试前提”与“代码逻辑不成立”分开，并把跳过原因写进报告。

Go testing 官方文档：https://pkg.go.dev/testing#T.Skip

条件不满足时用 Skipf 保留原因；断言不成立时继续使用 Error、Fatal 或显式失败。跳过不是隐藏错误，而是给测试结果加上准确语义。

把 Skip、Fail 和 Fatal 分开

可以先问一个简单问题：如果把缺少的外部条件补齐，当前断言是否还有机会执行？如果答案是“有”，这是跳过；如果答案是“已经执行且结果不符合预期”，这是失败。

Skip 会记录跳过状态并结束当前测试函数，SkipNow 是不带消息的立即跳过，Skipf 适合把环境值或缺失资源写入原因。Fatal 则表示当前测试已经遇到不可继续的失败，并立即结束当前测试 goroutine。三者都可能让后续代码不再执行，但报告语义完全不同。

用 Skipf 保留可读的跳过原因

最小写法是先判断测试前提，再调用 t.Skipf。原因应说明“缺少什么”以及“为什么本次不执行”，不要只写一个无法帮助定位的 skip。

package config_test

import (
    "os"
    "testing"
)

func TestRemoteConfig(t *testing.T) {
    endpoint := os.Getenv("TEST_CONFIG_ENDPOINT")
    if endpoint == "" {
        // 缺少外部测试前提时跳过，并把补齐条件写进报告。
        t.Skipf("缺少 TEST_CONFIG_ENDPOINT，无法执行远程配置测试")
    }

    // 前提已经具备，后面的断言才有实际意义。
    if endpoint == "disabled" {
        t.Fatalf("测试配置端点不可用: %s", endpoint)
    }
}

这里的环境变量只是示例。更重要的是判断位置：不要先创建连接、写临时文件或修改共享状态，最后才发现条件不满足。把前提判断放在测试边界，能减少无效副作用，也让报告中的原因和未执行的范围对应起来。

让条件测试的接口语义保持稳定

短测试通常会主动跳过慢速集成测试。用 testing.Short() 表达的是运行模式，而不是业务断言失败；这类原因同样应该写清楚。

func TestImportWithRealService(t *testing.T) {
    if testing.Short() {
        // -short 只运行快速测试，因此不把集成测试记为失败。
        t.Skip("短测试模式跳过真实服务依赖")
    }

    // 只有运行模式允许时，才连接真实服务并检查结果。
    if err := checkImportService(); err != nil {
        t.Fatalf("真实服务检查失败: %v", err)
    }
}

如果条件是可配置的，建议把变量名、资源名称和必要的补齐动作写进消息；如果条件来自测试数据本身，则应说明是哪一类输入不适用。不要把所有未知错误都转成跳过，否则真正的环境故障会从失败统计中消失。

子测试和模糊输入要按对象跳过

表驱动测试中，某一组数据不满足前提，不一定意味着整个父测试都应该退出。可以把条件放进对应的子测试，让报告保留更细的名字和原因。

func TestRegions(t *testing.T) {
    cases := []struct {
        name  string
        ready bool
    }{
        {name: "local", ready: true},
        {name: "remote", ready: false},
    }

    for _, tc := range cases {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            if !tc.ready {
                // 只跳过当前区域，其他子测试仍保持独立结果。
                t.Skipf("区域 %s 尚未准备测试数据", tc.name)
            }
            // 具备前提的子测试才执行实际断言。
            assertRegion(t, tc.name)
        })
    }
}

模糊测试也有类似边界：如果输入不符合被测格式，且这个输入本身不应算作失败，可以在模糊目标中调用 t.Skip；如果输入触发了应该成立的性质，却让断言失败或产生 panic，就不能用跳过掩盖问题。

几个容易混淆的判断

Skip 会让测试命令返回失败吗？

单独跳过通常不会被当成失败，但报告仍会保留 skipped 状态和消息。是否允许跳过、是否把跳过数量当作门禁，要由项目自己的 CI 规则决定。

应该用 Skip 还是 Skipf？

固定原因可以用 Skip；需要带环境变量、资源名或输入摘要时用 Skipf。无论选择哪一个，都要让读者知道为什么本次没有执行。

资源连接失败能直接 Skip 吗？

只有当该资源确实是可选测试前提、且项目明确允许缺失时才适合跳过。必需依赖启动失败通常应报告失败，否则 CI 可能在没有真正覆盖测试时仍显示健康。

SkipNow 和 Skipf 有什么区别？

SkipNow 立即跳过但不提供消息；Skipf 同样结束当前测试并格式化原因。实际工程里优先选择能留下诊断信息的写法。

最终可以把规则压缩成一句话：先判断测试前提，再决定结果语义；前提缺失用带原因的 Skipf，逻辑不成立才报告失败。这样测试报告既不会把环境差异伪装成代码缺陷，也不会用“跳过”掩盖应该修复的问题。