@TestFactory方法必须返回Stream/Collection/Iterable，数据需在方法体外层加载，每个DynamicTest需唯一可读名称并内嵌资源清理逻辑。
直接能用，但必须注意返回类型、数据加载时机和资源生命周期——否则测试会静默失败或泄漏。
返回值类型必须是 Stream/Collection/Iterable
@TestFactory 方法不是普通测试方法，它不执行断言，只负责“造出”测试。JUnit 5 严格校验返回类型：
- 允许的返回类型只有
Stream<dynamictest></dynamictest>、Collection<dynamictest></dynamictest>、Iterable<dynamictest></dynamictest>或Iterator<dynamictest></dynamictest> - 返回
List或ArrayList可以，但必须声明为Collection<dynamictest></dynamictest>接口类型（避免泛型擦除导致解析失败） - 返回
void或DynamicTest单个对象 → 直接报错org.junit.jupiter.api.extension.TestInstantiationException - Java 16+ 中若用
.toList()（不可变 List），需确认测试运行时类路径下 JUnit 版本 ≥ 5.8，否则可能抛UnsupportedOperationException
从文件读取数据时别在 lambda 里做 I/O
常见错误：把 BufferedReader 创建和 readLine() 放进 dynamicTest 的 lambda 里，导致每个测试都尝试打开同一文件，或因流已关闭而抛 IOException。
- 正确做法：在
@TestFactory方法体**最外层**完成数据加载，转成内存结构（如List<testdata></testdata>），再用stream().map(...)构建DynamicTest - 示例中读 CSV 时，用
Files.readAllLines(Paths.get("data.csv"))一次性加载，比手动 newFileReader更安全 - 如果数据量极大（>10MB），考虑用
Stream<string> lines = Files.lines(Paths.get("..."))</string>+onClose()确保流释放，但需包裹在 try-with-resources 外层，不能丢给 lambda 延迟执行
每个 DynamicTest 必须有唯一、可读的显示名
IDE 和 Maven Surefire 报告靠 DynamicTest 的第一个参数（String displayName）识别用例。命名含糊会导致调试困难：
- 避免静态名如
"test"或"case1"—— 所有动态测试在报告里显示为同一个名字，失败时无法区分哪组数据出问题 - 推荐格式：
"MathUtils_isEven_" + num或"API_POST_user_create_" + data.scenario - 若数据含特殊字符（如空格、斜杠、控制符），用
URLEncoder.encode(..., "UTF-8")处理，否则某些 CI 工具解析 XML 报告时会截断 - 名称长度建议 ≤ 120 字符；过长可能被截断，且影响 IntelliJ 测试窗格折叠体验
资源清理不能依赖 @BeforeEach/@AfterEach
这是最容易被忽略的坑：@BeforeEach 在整个 @TestFactory 方法执行前触发一次，不是对每个 DynamicTest 单独调用。
- 后果：数据库连接、临时文件、mock 静态状态等，会在所有动态测试间共享，造成干扰或泄漏
- 正确方式：把 setup/cleanup 逻辑写进每个
DynamicTest的Executablelambda 内部，例如：
dynamicTest("DB insert validation", () -> {
DataSource ds = TestDataSource.create();
try (Connection conn = ds.getConnection()) {
// 执行测试
assertTrue(insertUser(conn, user));
} finally {
ds.close(); // 显式释放
}
});
- 更健壮的做法是封装成工具方法，如
withCleanDataSource(ds -> { ... })，确保每次测试独占资源
