Golang跳过长时间测试 Short模式应用-小浪学习网

go语言中通过testing.Short()函数识别并标记长测试，开发者在测试中判断该函数返回值，若为true则调用t.Skip()跳过耗时或依赖外部资源的测试；如TestSomethingLongRunning中使用if testing.Short() { t.Skip(“…”) }实现短模式跳过；通常执行时间超几百毫秒或涉及网络、数据库操作的测试被视为长测试，需手动标记；在CI/CD中不应完全依赖-short模式，但可分阶段使用，如在快速预检阶段运行go test -short以快速反馈，再在后续阶段执行完整测试，确保覆盖率；为避免滥用导致覆盖不足，团队需建立规范明确标记范围，确保CI流水线始终运行完整测试，并通过代码审查和定期检查覆盖率防止测试遗漏。

Golang跳过长时间测试 Short模式应用

在go语言的测试体系中，

go test -short

命令提供了一种快速迭代的机制，它允许开发者在本地开发时，跳过那些耗时较长、通常涉及外部资源或大量计算的测试，从而显著加快测试反馈循环，提升开发效率。这就像是给你的测试套件装了个“快速模式”开关，让你能优先验证核心逻辑的正确性，而把全面的、耗时的验证留给持续集成（CI）环境。

解决方案

要应用

go test -short

模式，核心在于在你的测试代码中利用

testing

包提供的

testing.Short()

函数。这个函数会在你运行

go test -short

命令时返回

true

。因此，你可以在测试函数内部通过判断

testing.Short()

的返回值来决定是否跳过当前测试。

通常，我们会将那些需要访问数据库、进行网络请求、执行文件I/O操作、或者需要长时间计算的测试标记为“长测试”。一个典型的做法是：

package mypackage  import (     "testing"     "time" // 假设某个操作需要模拟耗时 )  func TestSomethingFast(t *testing.T) {     // 这是一个快速测试，无论是否是short模式都会运行     if 1+1 != 2 {         t.Errorf("Basic arithmetic failed")     } }  func TestSomethingLongRunning(t *testing.T) {     if testing.Short() {         t.Skip("Skipping long-running test in short mode") // 在short模式下跳过     }      // 模拟一个耗时操作，比如数据库查询、api调用等     time.Sleep(2 * time.Second)     t.Log("Long-running test completed successfully.") }  func TestAnotherLongRunningWithResource(t *testing.T) {     if testing.Short() {         t.Skip("Skipping resource-intensive test in short mode")     }      // 这里可以放置需要外部资源（如真实数据库连接）的测试逻辑     // 假设需要连接到外部服务     // client, err := connectToExternalService()     // if err != nil {     //     t.Fatal(err)     // }     // defer client.Close()     // ... 执行测试 ...     t.Log("Resource-intensive test completed.") }

当你执行

go test

时，所有测试都会运行。但当你执行

go test -short

时，

TestSomethingLongRunning

和

TestAnotherLongRunningWithResource

就会被跳过，因为它们内部检查了

testing.Short()

为

true

。这种机制让开发者能够灵活地控制测试的粒度和运行时间。

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

Go语言中如何识别并标记长时间测试？

识别长时间测试，这事儿说起来有点主观，但又很实际。通常，一个测试如果执行时间超过几百毫秒，或者它依赖外部服务、数据库，每次跑起来都得等个几秒甚至几十秒，那它就很有可能被归类为“长测试”了。我们写代码的时候，很容易就能感觉到哪个测试跑起来“肉”，因为它会拖慢整个测试套件的执行速度。

具体到识别上，你可以用

go test -v -bench .

来看看哪些基准测试（benchmarks）耗时，虽然这主要针对性能测试，但也能侧面反映出一些代码块的执行效率。更直接的方式，是留意

go test

完整运行一次需要多久。如果你的本地开发环境，每次修改代码后跑一遍测试要等个十几秒甚至更久，那么就得考虑哪些测试可以被跳过了。

标记嘛，就像前面代码示例里那样，直接在测试函数开头加个

if testing.Short() { t.Skip(...) }

就行。这其实是一种约定，也是一种开发纪律。团队内部可以约定一个阈值，比如“凡是需要网络请求的测试，或者执行时间预计超过1秒的，都应该在

short

模式下跳过”。这样，大家在写新测试时就能有个明确的指导。这种标记不是自动的，需要我们开发者手动判断和添加，这本身也是一种深思熟虑的体现，因为你知道哪些测试是你的“核心快检”，哪些是“深度体检”。

在CI/CD流水线中如何有效利用

go test -short

？

go test -short

模式在CI/CD流水线中的应用，其实是个有点意思的话题，它不像本地开发那样直观。毕竟，CI/CD的目标是确保代码质量，通常我们会希望在流水线中运行所有测试，包括那些耗时的集成测试和端到端测试，以提供最全面的质量保障。所以，直接在CI/CD中全面使用

-short

模式来替代完整测试，那绝对是自欺欺人，是不可取的。

但是，这并不意味着它在CI/CD里就毫无用武之地。想象一下，如果你的CI/CD流水线有多个阶段，比如“快速构建与单元测试”和“全面集成与部署测试”。在“快速构建”阶段，你可能需要一个极其迅速的反馈，比如在开发者提交代码到版本控制系统时，立即运行一个非常快的检查，以确保基本语法无误、核心单元测试通过，这时就可以考虑在这一阶段使用