Scala多项目执行sbt test时Config key not found问题求助

这种情况我在维护多模块sbt项目时也碰到过，核心原因基本都是sbt和IntelliJ处理测试classpath的逻辑不一致，导致配置文件的加载优先级或路径出现差异。结合你的项目结构，给你几个针对性的排查和解决方向：

1. 检查是否存在同名配置文件冲突 #

你的root项目把所有配置放在main/resources，而api/consumer模块的测试配置在各自的test/resources

如果root的main/resources里和子模块test/resources有同名的配置文件（比如都叫application.conf），sbt运行测试时会把root模块的main资源优先加入classpath，导致测试代码加载到的是root的配置，而非子模块测试目录下的配置——这就会出现"Config key not found"。而IntelliJ运行单个模块测试时，会把当前模块的test/resources放在classpath最前面，所以能正确加载测试配置。

解决办法：

• 给测试用的配置文件改个独特的名字，比如test-application.conf，然后在测试代码里明确指定加载这个文件；
• 或者在子模块的测试代码中，通过类加载器指定从测试资源目录加载：

val config = ConfigFactory.load(getClass.getResource("/application.conf"))

2. 调整子模块测试的classpath优先级 #

如果不想改配置文件名，可以在子模块的build.sbt中设置，让测试资源的优先级高于main资源：

Test / unmanagedClasspath := (Test / unmanagedResourceDirectories).classpath ++ (Test / unmanagedClasspath).value

这个配置会把当前模块的test/resources目录提前到classpath的前面，确保测试时优先加载测试目录的配置。

3. 确认子模块的测试资源被正确识别 #

有时候sbt可能因为自定义配置问题，没有把test/resources加入到测试的classpath中。可以在子模块的build.sbt中显式声明测试资源目录，确保sbt能正确识别：

Test / resourceDirectory := baseDirectory.value / "src" / "test" / "resources"

不过这是sbt的默认配置，大概率不需要改，但如果你的项目结构有自定义调整，可以检查一下。

4. 清理并重新生成sbt项目元数据 #

偶尔会因为编译缓存导致资源文件没有被正确复制到测试classpath目录，你可以在项目根目录执行以下命令清理缓存并重新编译：

sbt clean test:compile

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