从日志整体来看，并不是 Spring 容器本身无法启动，而是由于测试环境中启用了包括 QSchedule、Dubbo、Zookeeper 等在内的一整套"生产级"中间件，导致在测试阶段出现了大量连接外部服务、注册节点的操作，从而产生了一些看上去比较"吓人"的警告或堆栈信息。通常情况下，这些日志和堆栈并不一定会直接导致 Spring Boot Test **无法**完成初始化，更多是因为：
1. **ZK 节点已存在**（NodeExistsException）
- 日志里能看到多次"`org.apache.zookeeper.KeeperException$NodeExistsException`"的异常。这往往表示 Dubbo/ QSchedule 在尝试向 Zookeeper 注册临时节点（ephemeral node）时，发现 ZNode 已经被前一次会话(session)占用，但是 ZooKeeper 服务器端还没来得及清理掉（可能是上一次会话刚断开不久，或者是网络/session 超时尚未触发删除）。
- 在 Dubbo / QSchedule 的实现里，一旦发现"节点已存在"，会先打印一个栈追踪然后再尝试删除旧节点或直接覆盖，所以这并不一定是**致命错误**，更多是一个告警级别的提示。
2. **"No available executors" 等 Dubbo Warnings**
- 这类日志是 Dubbo 在启动阶段检查或引用服务时，尚未来得及创建执行线程池（ExecutorRepository）就去获取执行器，或是线程池池化策略暂时没准备好导致的警告。它同样不一定会导致启动失败，通常是内部逻辑或初始化顺序所致。
3. **外部配置不存在、无法读取本地配置**
- 你会看到类似"从本地读取不到配置: tc-qclient-redis.properties"、"no config file find in classpath"之类的信息，说明测试启动时 QConfig / QClientRedis 等组件在尝试获取线上或本地配置文件，没有找到时就会打出 WARN 日志。这在真实线上环境下往往通过配置中心(QConfig)解决，但如果在本地跑单测，还连接到线上或者测试环境的 ZK / QConfig，就会出现这种现象。
4. **Dubbo / Zookeeper 正常连上了远程服务**
- 日志中还能看到类似"Successed connect to server /10.86.xx.xx:xxxx from NettyClient..."之类的信息，其实说明 Dubbo 客户端已经成功连上服务器，也注册/订阅了节点；如果真的是 Spring Boot Test 无法初始化，一般会看到最终抛出异常、context refresh 失败并退出的情况。但从日志看（尤其是出现了很多后续输出），大概率说明容器实际上是**已经**初始化并在继续向下执行了。
---
## 如果你确实不希望在本地跑单测时就连到完整的外部环境
在日常开发中，**[[集成测试]]（Integration Test）**有时需要和真实或准真实的外部环境交互，但有些情况下我们只想做**单元测试（Unit Test）**或"**轻量级**"集成测试，不希望引入过多对外部 ZK、QSchedule、Dubbo 注册中心等的依赖。这时候可以考虑：
1. **排除某些自动配置**
- 如果这些 Dubbo / QSchedule / QConfig 的起步依赖是通过 `@EnableAutoConfiguration` 或者 Spring Boot Starter 注入的，可以在测试时通过 `@SpringBootTest(exclude = {...})` 或者在 `application-test.yml` 中关闭某些自动化配置。例如：
```yaml
spring:
# 若有对应 key 可以直接 disable
cloud:
qschedule:
enabled: false
# 或者
dubbo:
registry:
address: N/A
```
- 具体要看你项目里如何引入 QSchedule / Dubbo Starter，一般都能找到对应的 "enabled" 开关或者可以排除特定的 AutoConfiguration 类。
2. **使用 Mock / Stub 代替外部依赖**
- 比如如果只是测试 Mapper、Service 中的逻辑，与 QSchedule 无关，可以自己在测试里 `@MockBean` 掉那些需要连外部的接口或服务，让它们返回假数据，而不必真的启动 Dubbo 或连接 ZK。这种方法能显著简化测试环境。
3. **使用嵌入式 ZK 或测试容器**
- 对于真的需要 Zookeeper 场景，可以使用"Testing ZK"或"Testcontainers"之类的嵌入式容器/Mock 实现，避免连到真实的服务器（尤其是"beta"、"prod"等环境）。
- 同样也可以通过 Docker + Testcontainers 方式启动一个临时 ZK，这样测试结束就销毁，避免节点脏数据堆在 ZK 里影响下次测试。
4. **区分开发/测试环境的配套配置中心**
- 如果你的项目中还需要 QConfig、QClientRedis、Qmq 等，这些在本地跑测试同样会产生大量 WARN / ERROR（因为找不到远程文件）。可以做法包括：
- 在 `src/test/resources` 放置一个仅供单测使用的空/Mock 配置文件，让它绕过读取远端。
- 在 `application-test.properties` 或者对应的 YAML 里关掉 QConfig 加载，或者指向一个专门的"fake"配置服务器地址（如果支持的话）。
- 通过 `@ActiveProfiles("test")` 或者注入 JVM 参数 `-Dspring.profiles.active=test` 的方式，让测试时专用一个最简化的配置。
总之，如果你仅仅是想测试自己的业务代码（例如某些 Mapper、Service 的逻辑），那就**没必要**让整套分布式组件都在本地启动、连接；它们大概率会产生许多无关的警告、异常日志。可以通过"排除自动配置"+"MockBean"+"嵌入式替代"的做法，让单测变得更纯粹、可靠。
---
## 结论
- 日志中的堆栈大多是 **外部分布式组件**（Dubbo / QSchedule / QConfig / Zookeeper 等）在测试启动过程中的常见行为或警告，不一定意味着容器真的没起来。
- 如果测试后面没有出现 `Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.` 或类似的致命错误，基本可以说明 Spring 容器实际上是**成功**初始化了。
- 想要避免这些外部警告或 NodeExistsException，可以在测试时**尽量断开**对外依赖，或者使用 mock / stub / 关闭自动配置 / 内存替代等手段来做"轻量级"测试。这样既可以加快测试速度，也减少对外部环境的依赖和干扰。
- 如果你确实需要做一套**集成测试**，又想保证"干净"的 Zookeeper 环境，可以在每次测试前/后**手动或自动**清理 ZK 上的临时节点，或者使用短 sessionTimeout 并等待节点自然清理，也可借助 Testcontainers/嵌入式 ZK。
综上所述，这些日志并不代表 Spring Boot Test 真正初始化失败，更多是分布式组件在测试环境下的一些典型"嘈杂"日志，可以根据自身测试需求选择是否以及如何去掉它们。
根据你分享的 Application 类，我建议通过以下几种方式来优化单元测试:
1. 为测试创建一个专门的测试配置类:
```java
@Configuration
@ComponentScan(basePackages = "com.qunar.dzs.hotelsearch.polaris")
// 显式排除 Dubbo、QSchedule 等配置类
@EnableAutoConfiguration(exclude = {
DubboAutoConfiguration.class,
QScheduleAutoConfiguration.class,
QConfigAutoConfiguration.class
// 其他需要排除的自动配置类...
})
public class TestConfig {
// 可以在这里添加测试专用的 mock bean
}
```
1. 在测试类中使用这个测试配置:
```java
@SpringBootTest(
classes = TestConfig.class, // 使用测试专用配置
properties = {
"spring.cloud.qschedule.enabled=false",
"spring.dubbo.enabled=false",
"dubbo.enabled=false"
// 其他需要禁用的配置
}
)
public class PreRunTaskMapperTest {
// 如果需要 mock 某些 bean
@MockBean
private DubboService dubboService;
@Test
public void testXXX() {
// 测试代码
}
}
```
1. 创建测试专用的配置文件 `src/test/resources/application-test.yml`:
```yaml
spring:
cloud:
qschedule:
enabled: false
dubbo:
enabled: false
registry:
address: N/A
# 关闭其他外部依赖
qconfig:
enabled: false
qschedule:
enabled: false
```
1. 如果只想测试单个 Mapper，可以使用 `@MybatisTest`:
```java
@MybatisTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class PreRunTaskMapperTest {
@Autowired
private PreRunTaskMapper mapper;
@Test
void testMapper() {
// 测试代码
}
}
```
1. 对于需要事务的测试，可以用 `@Transactional` 注解:
```java
@SpringBootTest(classes = TestConfig.class)
@Transactional
class PreRunTaskMapperTest {
@Test
void testWithTransaction() {
// 测试完自动回滚
}
}
```
1. 如果需要模拟外部服务，可以使用 `@MockBean`:
```java
@SpringBootTest(classes = TestConfig.class)
class PreRunTaskMapperTest {
@MockBean
private QScheduleClient qScheduleClient;
@BeforeEach
void setup() {
when(qScheduleClient.someMethod())
.thenReturn(expectedResult);
}
@Test
void test() {
// 测试代码
}
}
```
1. 如果仅测试服务层逻辑，可以完全不启动 Spring 容器:
```java
@ExtendWith(MockitoExtension.class)
class ServiceTest {
@Mock
private PreRunTaskMapper mapper;
@InjectMocks
private YourService service;
@Test
void testService() {
// 纯单元测试，不启动 Spring
}
}
```
这些方法可以组合使用，关键是要根据你的具体测试需求选择合适的方案：
- 如果只测试 Mapper，用 `@MybatisTest`
- 如果测试 Service 但不需要外部依赖，用 `@MockBean` + `@SpringBootTest`
- 如果完全是单元测试，用 JUnit 5 + Mockito 就够了
- 如果需要完整的集成测试，那就配置测试专用的轻量级环境
这样可以让测试更加聚焦和高效，避免不必要的外部依赖干扰。