提升 Jenkins Pipeline Unit 测试速度的 5 个技巧：从 30s 优化到 3s

在 DevOps 领域，Jenkins Shared Libraries 的单元测试一直是开发者又爱又恨的存在。JenkinsPipelineUnit 框架虽然提供了强大的 Mock 能力，但随着库规模的扩大，测试套件运行越来越慢。原本为了提高效率的自动化测试，如果跑一次要半分钟，反而成了阻碍持续集成的负担。

本文总结了在生产实践中将单元测试耗时从 30 秒压缩至 3 秒的 5 个核心技巧。

1. 避免在每个测试用例中重复初始化

这是性能损耗最大的地方。默认情况下，很多开发者会在 setup() 或 before() 方法中调用 super.setUp()，这会导致每个 @Test 或 feature 都会重新初始化整个 Jenkins 运行环境（包括注册所有的 DSL 步骤）。

优化方案： 采用单例模式或利用 Spock 框架的 @Shared 变量。
将 PipelineTestHelper 的初始化提升到类级别，甚至跨类重用。

class BasePipelineTest extends Specification {
    @Shared static PipelineTestHelper helper
    @Shared static Object script

    def setupSpec() {
        // 全局只初始化一次环境
        helper = new PipelineTestHelper()
        helper.registerAllowedMethod("sh", [Map.class], null)
        // 加载通用的 Mock 逻辑
    }
}

2. 区分 src 类测试与 vars 脚本测试

Jenkins Shared Library 分为 src/ (标准 Groovy 类) 和 vars/ (全局变量/DSL 脚本)。

• 痛点： 使用 helper.loadScript() 加载 vars/ 脚本会涉及复杂的 DSL 解析和包装。
• 优化： 尽可能将核心逻辑写在 src/ 下的普通 Groovy 类中。

对于 src/ 中的类，直接使用 JUnit 5 或 Spock 原生测试，完全脱离 JenkinsPipelineUnit 框架。原生的 Groovy 类测试速度是毫秒级的，因为它不需要模拟 Jenkins 的环境变量和步骤执行器。

3. 精简 loadLibrary 的作用域

如果你的共享库依赖了其他庞大的库，或者在 setup 阶段加载了整个 vars/ 目录，IO 开销会非常明显。

优化方案：
不要每次都加载整个库，而是采用“按需注册”。如果你只需要测试某个步骤，手动使用 helper.registerAllowedMethod 注册该步骤，而不是通过 helper.loadLibrary 加载几十个脚本。

// 慢速方式
helper.loadLibrary("my-super-library@master")

// 快速方式
helper.registerAllowedMethod("myCustomStep", [String.class]) { args -> 
    return "mocked ${args}" 
}

4. 启用 Spock/JUnit 5 的并行执行

Jenkins Pipeline Unit 测试通常是 CPU 密集型的（涉及大量的反射和类加载）。现在的多核处理器完全可以支撑并行运行。

在 junit-platform.properties 中开启并行模式：

junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent

注意：如果你的测试代码中存在静态变量竞争，请配合 @Isolated 或线程安全的 Mock 工具使用。

5. 预热 Groovy 编译缓存

Groovy 是动态语言，首次加载脚本时需要动态编译成字节码。在 CI 环境中，如果每次都从零开始构建，编译开销很大。

优化方案：

1. 利用 Gradle Daemon： 确保在本地和 Jenkins Agent 上保持 Gradle Daemon 开启，利用其类加载缓存。
2. 减少动态反射： 在 Mock 复杂对象时，使用 GroovyMock 或 Map 代替真实的闭包代理。

总结：优化前后对比

通过以上调整，开发者的反馈周期将从“起身倒杯咖啡”缩短到“眨几次眼”。记住，最好的测试不仅要准，还要快。