当在 `@SpringBootTest` 中测试特定组件子集时，若存在同名但不同包的类（如 `com.foo.ConflictName` 和 `com.bar.ConflictName`），默认的 Bean 命名策略会导致 `BeanDefinitionOverrideException`。本文将详细介绍如何在 `SpringBootTest` 环境下，通过内联 `@Configuration` 类结合 `@ComponentScan` 和 `FullyQualifiedAnnotationBeanNameGenerator` 来解决这一问题，确保 Bean 能够基于其全限定类名正确注册，从而实现隔离测试。
理解 Bean 命名冲突问题
在 Spring 框架中，当多个类具有相同的简单名称（例如，com.foo.ConflictName 和 com.bar.ConflictName 都包含一个名为 ConflictName 的类）并被注册为 Spring Bean 时，如果使用默认的 Bean 命名策略，就会发生冲突。默认情况下，Spring 的 AnnotationBeanNameGenerator 会使用类的简单名称作为 Bean 的名称。这意味着 com.foo.ConflictName 和 com.bar.ConflictName 都可能被命名为 conflictName。
当在 @SpringBootTest 中指定一个包含这些冲突类的子集时，例如：
@SpringBootTest(
classes = [BarService::class, ConflictName::class, com.foo.ConflictName::class, FooService::class]
)
class DemoApplicationTests这会导致 org.springframework.beans.factory.support.BeanDefinitionOverrideException 异常，因为 Spring 尝试注册两个名为 conflictName 的 Bean。
然而，如果 @SpringBootTest 不指定 classes 参数，而是加载整个应用上下文，则可能不会出现此问题。这通常是因为在完整的 Spring Boot 应用中，我们可能已经通过 @SpringBootApplication 注解的 nameGenerator 属性，将 Bean 命名策略更改为使用全限定类名，例如 FullyQualifiedAnnotationBeanNameGenerator。
引入全限定 Bean 名称生成器
为了解决这种命名冲突，我们可以使用 FullyQualifiedAnnotationBeanNameGenerator。这个生成器会使用 Bean 的全限定类名（包括包名）作为其 Bean 名称，从而避免了简单名称冲突。
在标准的 Spring Boot 应用中，可以通过 @SpringBootApplication 注解来指定：
@SpringBootApplication(nameGenerator = FullyQualifiedAnnotationBeanNameGenerator::class) class DemoApplication
在 @SpringBootTest 中指定 Bean 名称生成器
对于 @SpringBootTest，尤其是当我们需要测试一个隔离的组件子集时，我们不能直接在 @SpringBootTest 注解上指定 nameGenerator。但可以通过在测试类内部定义一个 @Configuration 类，并结合 @ComponentScan 来实现相同的效果。
这种方法会为当前的测试创建一个独立的 Spring 应用上下文，而不会加载主应用程序的配置。
以下是具体的实现步骤和示例代码：
- 创建内部 @Configuration 类： 在你的 @SpringBootTest 测试类内部，定义一个 internal （Kotlin）或 static （Java）的 @Configuration 类。这个配置类将作为当前测试的根配置。
-
使用 @ComponentScan： 在这个内部 @Configuration 类上使用 @ComponentScan 注解。
- nameGenerator 参数： 将 nameGenerator 参数设置为 FullyQualifiedAnnotationBeanNameGenerator::class。
- basePackageClasses 参数： 使用 basePackageClasses 参数来指定需要扫描的组件所在的类。请注意，basePackageClasses 会扫描这些类所在的整个包，而不是仅仅包含这些类本身。
示例代码：
假设我们有以下冲突的组件：
// com/bar/ConflictName.kt package com.bar import org.springframework.stereotype.Component @Component class ConflictName // com/foo/ConflictName.kt package com.foo import org.springframework.stereotype.Component @Component class ConflictName
以及依赖它们的 Service：
// com/bar/BarService.kt package com.bar import org.springframework.stereotype.Service @Service class BarService(private val conflictName: ConflictName) // com/foo/FooService.kt package com.foo import org.springframework.stereotype.Service @Service class FooService(private val conflictName: ConflictName)
现在，我们可以在 @SpringBootTest 中这样配置：
package com
import org.junit.jupiter.api.Assertions
import org.junit.jupiter.api.Test
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.context.annotation.ComponentScan
import org.springframework.context.annotation.Configuration
import org.springframework.context.annotation.FullyQualifiedAnnotationBeanNameGenerator
@SpringBootTest
class DemoApplicationTests {
// 1. 定义一个内部的 @Configuration 类
@Configuration
// 2. 使用 @ComponentScan 指定 nameGenerator 和要扫描的基类
@ComponentScan(
nameGenerator = FullyQualifiedAnnotationBeanNameGenerator::class,
basePackageClasses = [com.foo.ConflictName::class, com.bar.ConflictName::class]
)
// 这是一个空的内部配置类，它将作为此测试的上下文配置
internal class IsolatedTestConfig
// 注入以验证 Bean 是否被正确创建
@Autowired(required = false)
var springBootApp: org.springframework.boot.SpringApplication? = null
@Autowired(required = false)
var compFoo: com.foo.ConflictName? = null
@Autowired(required = false)
var compBar: com.bar.ConflictName? = null
@Test
fun testNamingAndIsolation() {
// 验证主 SpringApplication 没有被加载，因为我们使用了隔离配置
Assertions.assertNull(springBootApp)
// 验证两个冲突的 Bean 都被成功创建并注入
Assertions.assertNotNull(compFoo)
Assertions.assertNotNull(compBar)
}
}注意事项与总结
- 上下文隔离： 上述方法通过在 @SpringBootTest 中定义一个内部的 @Configuration 类，实际上是为该测试创建了一个完全独立的 Spring 应用上下文。这意味着它不会加载主应用程序（通过 @SpringBootApplication 定义的）的配置。因此，在 testNamingAndIsolation 方法中，springBootApp 会是 null。
- @TestConfiguration vs. @Configuration： 如果你的目标是修改或增强主应用程序的上下文，而不是完全替换它，那么应该使用 @TestConfiguration。然而，在本例中，我们希望创建一个全新的、隔离的上下文来解决 Bean 命名冲突，因此 @Configuration 是更合适的选择。
- basePackageClasses 的作用： basePackageClasses 参数会指示 @ComponentScan 扫描指定类所在的包。这意味着如果 com.foo.ConflictName 在 com.foo 包中，那么整个 com.foo 包都会被扫描。请根据你的实际需求调整 basePackageClasses，以确保只扫描必要的组件。
- Bean 命名： 采用 FullyQualifiedAnnotationBeanNameGenerator 后，com.foo.ConflictName 将被命名为 com.foo.ConflictName，而 com.bar.ConflictName 将被命名为 com.bar.ConflictName，从而避免了 BeanDefinitionOverrideException。
通过这种方式，我们可以在 @SpringBootTest 环境下，灵活地控制 Bean 的命名策略，有效解决因类名冲突导致的 Bean 定义异常，确保测试的稳定性和隔离性。
