为何Spring Batch测试未默认包含ScriptItemProcessor的脚本引擎依赖？

我在使用Spring Batch的ScriptItemProcessor时发现，测试JavaScript、Groovy、JRuby等多种脚本语言时，groovy-jsr223这类脚本引擎依赖默认未被包含，甚至测试范围也未引入。这导致部分测试会因环境中缺少对应引擎而被跳过。

例如，ScriptItemProcessorTests类中的Groovy测试代码如下：

@Test
void testGroovyScriptSourceSimple() throws Exception {
    assumeTrue(languageExists("groovy"));
    ScriptItemProcessor<String, Object> scriptItemProcessor = new ScriptItemProcessor<>();
    scriptItemProcessor.setScriptSource("item.toUpperCase();", "groovy");
    scriptItemProcessor.afterPropertiesSet();

    assertEquals("SS", scriptItemProcessor.process("ss"), "Incorrect transformed value");
}

该测试使用assumeTrue(languageExists("groovy"))，意味着仅当Groovy引擎可用时才会运行。但Spring Batch项目并未包含Groovy依赖，因此除非手动添加，否则测试会被跳过。

针对这一现象，以下是对应问题的解答：

1. 为何这些脚本引擎依赖（如groovy-jsr223）即使在测试场景下也未被Spring Batch项目默认包含？ #

• 框架轻量化原则：Spring Batch作为通用批处理框架，核心目标是保持依赖精简，只包含核心功能必需的组件。脚本引擎属于可选扩展能力，并非所有用户都会用到，默认引入会无端增加项目的依赖体积和构建时间。
• 避免版本冲突风险：不同脚本引擎有各自的版本迭代节奏和依赖生态，默认引入可能与用户项目中已存在的同类型依赖（比如用户自己引入的特定版本Groovy）产生版本冲突，提升集成难度。

2. 既然这些脚本是测试的一部分，框架为何要避免添加此类依赖？ #

• 测试的兼容性验证定位：这类测试设计的初衷是验证「当对应脚本引擎存在时，ScriptItemProcessor能正常工作」，而非要求所有环境都必须运行所有测试。使用assumeTrue跳过无依赖的场景，能保证测试套件在任何环境下都能顺利执行完成，不会因缺少可选依赖而失败。
• 控制维护成本：引入额外的测试依赖，意味着框架维护者需要持续跟进这些依赖的版本更新、安全补丁，增加维护负担。同时，并非所有贡献者或CI流水线都需要验证全脚本引擎的兼容性，默认引入反而会给不需要的场景带来不必要的成本。

3. 我们是否应该添加所需脚本引擎依赖，确保这些测试能作为测试流程的一部分自动运行？ #

分场景来看：

• 作为框架维护者：建议将这类依赖添加到**可选测试配置（如Maven/Gradle Profile）**中。比如创建script-engines专属Profile，让需要验证全脚本引擎兼容性的开发者或CI流水线可以主动激活该Profile来运行所有测试，同时保持默认测试套件的轻量化。
• 作为项目开发者：在自身测试环境中添加测试范围的脚本引擎依赖完全合理。这样可以在本地完整验证ScriptItemProcessor对目标脚本引擎的支持逻辑，提前发现依赖缺失或功能适配问题，避免在生产环境踩坑。
• 注意事项：添加依赖时要指定合适的版本，避免与项目中已有依赖产生冲突；同时通过Maven的scope=test或Gradle的testImplementation声明，确保依赖仅作用于测试阶段，不会被打包到生产产物中。

内容的提问来源于stack exchange，提问作者yeonnex