在 micronaut 库（io.micronaut.library）中直接编写 @micronauttest 集成测试会失败，因其默认不启动嵌入式服务器；正确做法是将需 http 集成验证的测试迁移至主应用模块（使用 io.micronaut.application 插件），或在库模块中显式启用测试服务器运行时。
在 micronaut 库（io.micronaut.library）中直接编写 @micronauttest 集成测试会失败，因其默认不启动嵌入式服务器；正确做法是将需 http 集成验证的测试迁移至主应用模块（使用 io.micronaut.application 插件），或在库模块中显式启用测试服务器运行时。
Micronaut 的模块化设计要求严格区分库（library） 与应用（application） 的职责：io.micronaut.library 插件仅提供编译与依赖管理能力，不包含任何运行时容器启动逻辑——这意味着即使你添加了 @MicronautTest，测试上下文也不会自动拉起 Netty 或 Tomcat 等嵌入式服务器，导致 HttpClient 连接 http://127.0.0.1:8080/ 时永久阻塞或超时。
✅ 正确方案一：将集成测试移至应用模块（推荐）
这是最符合 Micronaut 架构约定的做法。你的 HumansController 属于可复用组件，应保留在 common 库模块中；而端到端 HTTP 测试（如调用 /humans.txt 并校验响应）应在消费该库的主应用模块中执行：
// 在主应用模块的 build.gradle 中（使用 io.micronaut.application）
plugins {
id "io.micronaut.application" version "4.6.0" // 与 micronautVersion 一致
}
dependencies {
implementation project(':fri-so-common') // 引入你的库
testImplementation "io.micronaut:micronaut-http-client"
}
然后在主应用模块下编写测试：
package com.example.app;
import io.micronaut.http.client.HttpClient;
import io.micronaut.test.extensions.junit5.annotation.MicronautTest;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
@MicronautTest // ✅ 此时会自动启动 Netty 服务器
class HumansControllerIntegrationTest {
@Test
void testHumansTxtEndpoint(HttpClient client) {
String body = client.toBlocking()
.retrieve("/humans.txt");
assertNotNull(body);
assertTrue(body.contains("User-agent"));
}
}
? 注意：@MicronautTest 会自动注入已配置的 HttpClient bean，无需手动 create(new URL(...)) —— 这不仅更简洁，还确保使用的是测试上下文中的真实服务实例（含拦截器、安全配置等）。
✅ 正确方案二：在库模块中启用测试服务器（进阶）
若确需在库模块内运行 HTTP 集成测试（例如构建时独立验证），必须显式声明测试运行时依赖并启用服务器：
// build.gradle（库模块）
apply plugin: "io.micronaut.library"
micronaut {
runtime("netty") // ← 关键：声明运行时为 netty
testRuntime("junit5")
}
dependencies {
api("io.micronaut:micronaut-http")
api("io.micronaut:micronaut-http-server")
// ? 必须添加：使测试上下文能启动服务器
testImplementation("io.micronaut:micronaut-http-server-netty")
testImplementation("io.micronaut:micronaut-http-client")
testRuntimeOnly("ch.qos.logback:logback-classic") // 可选：日志支持
}
同时，修正测试类以使用 Micronaut 自动注入的 HttpClient：
@MicronautTest(startApplication = true) // 显式启动应用（关键！）
class HumansControllerTest {
@Test
void testHumansTxt(HttpClient client) { // ✅ 自动注入，非 new HttpClient.create(...)
String response = client.toBlocking().retrieve("/humans.txt");
assertTrue(response.contains("User-agent"));
}
}
⚠️ 注意事项：
- startApplication = true 是必需的（默认为 false 在库模块中）；
- @MicronautTest 会扫描当前模块及依赖模块中的 @Controller、@Bean 等，确保 HumansController 被加载；
- 若 humans.txt 位于 src/test/resources，请确认其路径为 classpath:humans.txt，且资源被正确打包进测试 classpath。
❌ 常见错误规避
-
错误写法：HttpClient.create(new URL("http://127.0.0.1:8080/"))
→ 硬编码地址不可靠，且未等待服务器就绪；应始终依赖 Micronaut 注入的 HttpClient。 - 遗漏依赖：仅加 micronaut-http-server 不够，必须添加具体实现（如 micronaut-http-server-netty）。
- 插件误用：在库模块中错误应用 io.micronaut.application 插件会导致构建冲突，应严格分离职责。
总结
Micronaut 的“库 vs 应用”分层不是限制，而是工程最佳实践的体现。控制器的逻辑正确性可通过单元测试（@Inject + 模拟 ResourceLoader）在库模块内充分覆盖；而 HTTP 协议层行为（路由、状态码、内容协商）应由应用模块的集成测试保障。 这样既保证可复用性，又避免测试环境耦合，符合云原生微服务的演进范式。
