Apache Druid扩展开发：解决SQL聚合函数测试中的ComponentSupplier配置问题

背景介绍

在Apache Druid扩展开发过程中，为系统添加自定义SQL聚合函数是一个常见需求。开发者通常需要编写单元测试来验证这些自定义函数的正确性。然而，近期在Druid 32版本之后，原有的测试框架API发生了重大变化，导致许多基于旧版本编写的测试用例无法正常运行。

问题现象

开发者在实现自定义聚合函数测试时遇到了一个典型错误："Cannot read field 'componentSupplier' because 'config' is null"。这个错误发生在尝试使用@ComponentSupplier注解配置测试环境时，表明测试框架未能正确初始化Guice依赖注入配置。

技术分析

组件供应机制

Apache Druid的测试框架使用Guice进行依赖注入管理。@ComponentSupplier注解原本用于指定测试类使用的组件供应器，但在框架升级后，其工作方式发生了变化。核心问题在于：

1. 测试框架期望通过JUnit 5扩展机制自动初始化配置
2. 当测试类使用JUnit 4的@Test注解时，初始化流程会被跳过
3. 导致SqlTestFrameworkConfig无法正确建立组件供应器映射

框架演进

从Druid 32版本开始：

• 移除了原有的configureGuice方法
• 改为基于注解的自动配置方式
• 强化了与JUnit 5的集成

解决方案

临时解决方案

通过手动初始化配置可以临时解决问题：

private static void initializeGuiceConfiguration() {
    List<Annotation> annotations = List.of(TestClass.class.getAnnotations());
    queryFrameworkRule.setConfig(new SqlTestFrameworkConfig(annotations));
}

这种方法虽然有效，但违背了框架设计的初衷，不是最佳实践。

推荐方案

正确的做法是：

1. 确保使用JUnit 5的测试注解（org.junit.jupiter.api.Test）
2. 完整实现组件供应器类
3. 正确配置测试类注解

示例组件供应器实现：

public class CustomComponentSupplier extends SqlTestFramework.StandardComponentSupplier {
    public CustomComponentSupplier(TempDirProducer tempDirProducer) {
        super(tempDirProducer);
    }

    @Override
    public DruidModule getCoreModule() {
        return DruidModuleCollection.of(
            super.getCoreModule(),
            new CustomExtensionModule()
        );
    }
}

最佳实践

1. 版本适配：针对Druid 32+版本，应使用新的测试框架API
2. 注解规范：统一使用JUnit 5的测试注解
3. 模块管理：在组件供应器中明确声明所有需要的模块
4. 环境隔离：确保每个测试类有独立的配置环境

总结

Apache Druid测试框架的演进带来了更现代的编程模型，但也需要开发者适应新的API使用方式。理解Guice在测试环境中的工作机理，以及JUnit 5扩展点的加载时机，对于编写可靠的扩展测试至关重要。当遇到配置问题时，检查注解版本和初始化流程往往是解决问题的关键。

对于正在迁移旧测试代码的开发者，建议全面升级到JUnit 5，并参考最新的官方示例代码，这能避免许多潜在的兼容性问题，也能更好地利用框架提供的新特性。