Golang测试如何跳过耗时用例合理使用Short和Skip方法-Golang-PHP中文网

在golang中跳过耗时测试的核心方法是结合testing.short()与t.skip()。1. testing.short()用于判断是否处于短模式运行；2. 若为真，则通过t.skip()跳过当前测试；3. 日常开发或ci早期阶段可用go test -short快速执行核心测试，而完整验证阶段则运行全部用例；4. 耗时测试通常包括网络请求、文件i/o、复杂计算、集成及端到端测试；5. 应避免过度跳过导致覆盖率下降、死代码积累和调试困难；6. 最佳实践包括区分测试类型、明确跳过理由、组织测试文件、合理设置ci策略并持续优化测试性能。

Golang测试如何跳过耗时用例合理使用Short和Skip方法

在Golang的测试中，如果你想灵活控制哪些耗时用例在日常开发或特定场景下运行，而哪些则跳过，核心的解决方案是巧妙地运用

testing

登录后复制

包提供的

testing.Short()

登录后复制

函数以及测试方法中的

t.Skip()

登录后复制

方法。

Short()

登录后复制

用于判断当前是否处于“短模式”运行状态，而

t.Skip()

登录后复制

则能直接让当前测试用例停止并被标记为跳过。

Golang测试中，要跳过耗时用例，主要依赖

testing

登录后复制

包提供的

testing.Short()

登录后复制

和

t.Skip()

登录后复制

方法。

Short()

登录后复制

用于判断是否在短模式下运行，而

t.Skip()

登录后复制

则直接跳过当前测试。

解决方案

要实现测试用例的跳过，我们通常会将

testing.Short()

登录后复制

与

t.Skip()

登录后复制

结合起来使用。

testing.Short()

登录后复制

是一个全局函数，它会返回一个布尔值，表示测试是否以短模式运行（即通过

go test -short

登录后复制

命令）。当你在一个测试函数内部调用

t.Skip()

登录后复制

时，当前的测试会立即停止执行，并被标记为“跳过”（skipped），而不会被认为是失败。

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

具体来说，你可以这样组织你的测试代码：

package mypackage

import (
    "fmt"
    "testing"
    "time"
)

// TestFast 是一个普通的快速单元测试
func TestFast(t *testing.T) {
    // 模拟一个快速操作
    result := 10 + 20
    if result != 30 {
        t.Errorf("Expected 30, got %d", result)
    }
    fmt.Println("TestFast completed quickly.")
}

// TestTimeConsuming 是一个可能需要较长时间的测试，例如涉及网络或文件I/O
func TestTimeConsuming(t *testing.T) {
    // 如果当前测试是短模式运行，则跳过此测试
    if testing.Short() {
        t.Skip("Skipping TestTimeConsuming in short mode. Use 'go test' without -short to run it.")
    }

    // 模拟一个耗时操作，比如等待外部服务响应或处理大量数据
    fmt.Println("Starting TestTimeConsuming... This will take a moment.")
    time.Sleep(3 * time.Second) // 模拟3秒的延迟
    fmt.Println("TestTimeConsuming finished after a delay.")

    // 实际的测试断言
    data := "processed_data"
    if data == "" {
        t.Error("Expected processed data, got empty.")
    }
}

// TestExternalDependency 是一个依赖外部服务的测试
func TestExternalDependency(t *testing.T) {
    if testing.Short() {
        t.Skip("Skipping TestExternalDependency in short mode.")
    }

    // 假设这里会尝试连接数据库或第三方API
    fmt.Println("Attempting to connect to external service...")
    // 模拟连接失败或耗时
    if false { // 假设条件判断为假，表示连接成功或测试通过
        t.Error("Failed to connect to external service.")
    }
    fmt.Println("External service test completed.")
}

登录后复制

当你运行

go test

登录后复制

时，所有测试都会运行，包括

TestTimeConsuming

登录后复制

和

TestExternalDependency

登录后复制

。而当你运行

go test -short

登录后复制

时，

TestTimeConsuming

登录后复制

和

TestExternalDependency

登录后复制

这两个用例会被

t.Skip()

登录后复制

跳过，从而大大加快测试执行速度。

如何判断一个测试用例是否“耗时”，以及何时应该跳过？

说实话，判断一个测试用例是否“耗时”并没有一个绝对的标准，它更多地取决于你的项目规模、团队的开发节奏以及对快速反馈的需求。但通常来说，那些涉及以下情况的测试，就很有可能被归类为“耗时用例”：

网络请求或外部服务调用： 比如调用HTTP API、数据库查询、消息队列交互等。这些操作的延迟是不可控的，而且可能因为网络波动或服务不稳定而变得非常慢。
文件I/O操作： 读写大文件，或者进行大量的文件系统操作。
复杂的计算或算法： 某些计算密集型任务，特别是当输入数据规模很大时。
集成测试（Integration Tests）： 这些测试通常需要启动多个服务或组件，模拟真实环境，其设置和 teardown 过程本身就可能耗时。
端到端测试（End-to-End Tests）： 涉及用户界面自动化、跨多个系统流程的测试，往往是最慢的。

至于何时应该跳过，我的经验是：

日常开发迭代： 当你在本地频繁修改代码、需要快速验证单元功能时，跳过耗时用例能显著提升开发效率。你不想为了一行代码的改动，就等上几分钟的集成测试。
持续集成（CI）的早期阶段： 在每次代码提交（push）到版本库后，CI系统可能会触发一个快速的构建和测试流程。这时，只运行单元测试和少量的快速集成测试，可以提供即时反馈，避免浪费宝贵的CI资源。
资源受限的环境： 在一些测试环境（比如本地开发机、内存较小的CI代理）上，完整运行所有测试可能会导致资源耗尽或测试超时。
暂时性问题： 如果某个外部服务暂时不可用，导致依赖它的测试持续失败，为了不阻塞CI流程，可以暂时跳过这些测试，但务必记录下来，待问题解决后恢复。

关键在于权衡：跳过是为了速度，但不能牺牲质量。那些核心的、不依赖外部环境的单元测试，通常不应该被跳过。

testing.Short()

登录后复制

和

t.Skip()

登录后复制

在实际项目中如何配合使用？有没有最佳实践？

在实际项目中，

testing.Short()

登录后复制

和

t.Skip()

登录后复制

的配合使用是门艺术，目的就是为了在开发效率和测试覆盖率之间找到一个平衡点。

区分测试类型：

AppMall应用商店
AI应用商店，提供即时交付、按需付费的人工智能应用服务

56

查看详情
- 单元测试： 尽量保持快速，不依赖外部环境，通常不使用
```
t.Skip()
```
  登录后复制
  。
- 集成测试/端到端测试： 这些是
```
testing.Short()
```
  登录后复制
  和
```
t.Skip()
```
  登录后复制
  的最佳使用场景。将它们放在单独的测试文件或包中，或者使用
```
build tags
```
  登录后复制
  来区分，这样可以更灵活地控制它们的运行。
明确跳过逻辑：
- 在
```
if testing.Short() { t.Skip(...) }
```
  登录后复制
  语句中，提供清晰的跳过理由。比如“在短模式下跳过耗时测试”或“跳过需要外部数据库的测试”。这对于后续维护和理解测试行为至关重要。
- 如果测试依赖某个环境变量或配置，也可以用
```
t.Skip()
```
  登录后复制
  。例如：
```
if os.Getenv("RUN_INTEGRATION_TESTS") != "true" {
    t.Skip("Skipping integration test: RUN_INTEGRATION_TESTS not set.")
}
```
  登录后复制
CI/CD策略：
- 快速反馈阶段： 在每次代码提交时，CI流水线可以先运行
```
go test -short
```
  登录后复制
  ，确保基本功能没有问题。这提供了快速的绿色/红色反馈。
- 完整验证阶段： 在合并到主分支、发布前，或者每天晚上，CI流水线可以运行完整的
```
go test
```
  登录后复制
  （不带
```
-short
```
  登录后复制
  ），确保所有耗时测试和集成测试都通过。
- 考虑使用不同的CI作业来运行不同类型的测试，比如一个
```
unit-test
```
  登录后复制
  作业和一个
```
e2e-test
```
  登录后复制
  作业。
测试文件组织：
- 一种常见的做法是将耗时的集成测试放在一个独立的包（例如
```
./integration_tests
```
  登录后复制
  ）中，或者在文件名上加以区分（例如
```
my_feature_integration_test.go
```
  登录后复制
  ）。
- 或者，利用Go的
```
build tags
```
  登录后复制
  ：
```
// +build integration

package mypackage

import "testing"

func TestHeavyIntegration(t *testing.T) {
    // ...
}
```
  登录后复制
  然后通过
```
go test -tags=integration
```
  登录后复制
  来专门运行这些测试，或者在默认情况下不运行它们。
避免过度跳过：
- 不要因为一个测试偶尔失败就将其跳过。这会掩盖真实问题，导致技术债累积。应该修复测试或代码。
- 确保所有跳过的测试最终都会在某个阶段被运行到。

跳过测试用例可能带来哪些潜在问题？如何权衡测试速度与覆盖率？

跳过测试用例，就像是给测试流程开了个“加速器”，但任何加速都有其代价。它可能带来一些潜在的问题，需要我们小心应对：

降低测试覆盖率的假象： 最直接的问题是，你可能认为你的测试通过了，但实际上有部分关键代码路径或集成场景根本没有被测试到。这会给人一种“假性安全感”，导致缺陷溜进生产环境。
“死代码”或未发现的回归： 如果一个被跳过的测试所对应的功能发生了变化，或者其依赖的外部服务行为改变了，你可能无法及时发现问题，直到用户抱怨或生产环境崩溃。被跳过的测试就像是代码库里的“盲区”。
测试债务累积： 如果团队成员习惯性地跳过耗时测试而不去优化它们，这些测试就可能永远不会被运行。它们成了测试代码库里的“僵尸”，既占地方又没有实际价值。
调试困难： 当生产环境出现问题时，如果相关的集成测试或端到端测试长期被跳过，你可能会发现很难在本地或测试环境中复现问题，因为你缺乏一个能快速验证的自动化流程。

所以，权衡测试速度与覆盖率，这是一个持续的挑战，没有一劳永逸的方案。我的看法是：

理解测试金字塔： 这是核心理念。构建一个健康的测试金字塔，底层是大量快速、独立的单元测试，中间是数量适中的集成测试，顶层是少量但全面的端到端测试。单元测试应该尽可能快，不应被跳过。耗时测试通常位于金字塔的中上层。
分层测试策略：
- 本地开发： 专注于单元测试，使用
```
go test -short
```
  登录后复制
  跳过集成/端到端测试，以获得最快的反馈。
- CI/CD早期： 运行单元测试和部分快速集成测试，确保基本质量。
- CI/CD晚期/发布前： 运行所有测试，包括耗时的集成和端到端测试。这可能是每晚执行一次，或者在合并到主分支、部署到预发布环境时触发。
持续优化测试： 不要仅仅因为一个测试耗时就永远跳过它。定期审视耗时测试，看看能否优化其性能，比如：
- 使用内存数据库而不是真实数据库。
- 模拟（Mock）外部服务或复杂依赖。
- 并行运行测试（Go的
```
go test
```
  登录后复制
  默认就是并行的，但也要注意测试间的隔离）。
- 缩小测试数据规模。
可见性和管理： 确保团队成员都知道哪些测试被跳过，为什么被跳过，以及它们何时会被运行。可以在测试报告中明确标记跳过的测试。一些CI工具也提供仪表盘来监控测试执行情况，包括跳过的测试。
自动化与人工的结合： 即使自动化测试有盲区，也要辅以人工探索性测试或定期手动回归测试，以捕捉自动化测试未能覆盖的边缘情况。