在golang中跳过耗时测试的核心方法是结合testing.short()与t.skip()。1. testing.short()用于判断是否处于短模式运行；2. 若为真，则通过t.skip()跳过当前测试；3. 日常开发或ci早期阶段可用go test -short快速执行核心测试，而完整验证阶段则运行全部用例；4. 耗时测试通常包括网络请求、文件i/o、复杂计算、集成及端到端测试；5. 应避免过度跳过导致覆盖率下降、死代码积累和调试困难；6. 最佳实践包括区分测试类型、明确跳过理由、组织测试文件、合理设置ci策略并持续优化测试性能。
在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 mypackageimport ( "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/Ofunc 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()
testing.Short()
和
t.Skip()
在实际项目中如何配合使用？有没有最佳实践？
在实际项目中，
testing.Short()
和
t.Skip()
的配合使用是门艺术，目的就是为了在开发效率和测试覆盖率之间找到一个平衡点。
区分测试类型：
单元测试： 尽量保持快速，不依赖外部环境，通常不使用
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 integrationpackage mypackageimport "testing"func TestHeavyIntegration(t *testing.T) { // ...}
然后通过
go test -tags=integration
来专门运行这些测试，或者在默认情况下不运行它们。
避免过度跳过：
不要因为一个测试偶尔失败就将其跳过。这会掩盖真实问题，导致技术债累积。应该修复测试或代码。确保所有跳过的测试最终都会在某个阶段被运行到。
跳过测试用例可能带来哪些潜在问题？如何权衡测试速度与覆盖率？
跳过测试用例，就像是给测试流程开了个“加速器”，但任何加速都有其代价。它可能带来一些潜在的问题，需要我们小心应对：
降低测试覆盖率的假象： 最直接的问题是，你可能认为你的测试通过了，但实际上有部分关键代码路径或集成场景根本没有被测试到。这会给人一种“假性安全感”，导致缺陷溜进生产环境。“死代码”或未发现的回归： 如果一个被跳过的测试所对应的功能发生了变化，或者其依赖的外部服务行为改变了，你可能无法及时发现问题，直到用户抱怨或生产环境崩溃。被跳过的测试就像是代码库里的“盲区”。测试债务累积： 如果团队成员习惯性地跳过耗时测试而不去优化它们，这些测试就可能永远不会被运行。它们成了测试代码库里的“僵尸”，既占地方又没有实际价值。调试困难： 当生产环境出现问题时，如果相关的集成测试或端到端测试长期被跳过，你可能会发现很难在本地或测试环境中复现问题，因为你缺乏一个能快速验证的自动化流程。
所以，权衡测试速度与覆盖率，这是一个持续的挑战，没有一劳永逸的方案。我的看法是：
理解测试金字塔： 这是核心理念。构建一个健康的测试金字塔，底层是大量快速、独立的单元测试，中间是数量适中的集成测试，顶层是少量但全面的端到端测试。单元测试应该尽可能快，不应被跳过。耗时测试通常位于金字塔的中上层。分层测试策略：本地开发： 专注于单元测试，使用
go test -short
跳过集成/端到端测试，以获得最快的反馈。CI/CD早期： 运行单元测试和部分快速集成测试，确保基本质量。CI/CD晚期/发布前： 运行所有测试，包括耗时的集成和端到端测试。这可能是每晚执行一次，或者在合并到主分支、部署到预发布环境时触发。持续优化测试： 不要仅仅因为一个测试耗时就永远跳过它。定期审视耗时测试，看看能否优化其性能，比如：使用内存数据库而不是真实数据库。模拟（Mock）外部服务或复杂依赖。并行运行测试（Go的
go test
默认就是并行的，但也要注意测试间的隔离）。缩小测试数据规模。可见性和管理： 确保团队成员都知道哪些测试被跳过，为什么被跳过，以及它们何时会被运行。可以在测试报告中明确标记跳过的测试。一些CI工具也提供仪表盘来监控测试执行情况，包括跳过的测试。自动化与人工的结合： 即使自动化测试有盲区，也要辅以人工探索性测试或定期手动回归测试，以捕捉自动化测试未能覆盖的边缘情况。
最终，目标是建立一个高效且可靠的测试体系，让开发者能够快速迭代，同时又能保证软件的质量。跳过测试是工具，而不是逃避问题的借口。
以上就是Golang测试如何跳过耗时用例 合理使用Short和Skip方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1399680.html
微信扫一扫 
支付宝扫一扫 
