JUnit模块化冲突源于org.junit被多模块导出，需统一父模块依赖并清理IDE重复库；测试非public成员须用反射+setAccessible(true)，但优先验证公开行为；测试类必须public，方法须public void无参，且注意Assert类与依赖完整性。
JUnit在模块化项目中遇到包访问权限冲突和变量测试难点，核心在于模块系统对包可见性的严格管控，以及JUnit对测试类/方法签名的硬性要求。问题不是孤立的，而是模块结构、依赖管理与测试规范三者交叠的结果。
模块化下org.junit包被多处引入的解决方法
Java 9+ 的模块系统禁止同一个包从多个模块导出，而JUnit相关类（如org.junit）一旦被junit.jar和另一个含JUnit的库（比如某些测试工具或旧版IDE插件自带的jar）同时提供，就会触发“The package org.junit is accessible from more than one module”错误。
- 检查构建配置：Maven中运行
mvn dependency:tree -Dverbose，定位重复引入JUnit的模块；Gradle中用./gradlew dependencies查看依赖树，排除传递性引入的多余JUnit版本 - 统一由父模块声明JUnit依赖：若为多模块项目，只在根pom.xml或settings.gradle中声明JUnit依赖，并设
test - 清理IDE缓存：IntelliJ中执行
File → Invalidate Caches and Restart；Eclipse中右键项目→Properties → Java Build Path → Libraries，手动移除重复添加的JUnit库条目 - 避免使用JVM参数绕过：像
-XX:+UseUniqueClassloader这类方式属于临时规避，可能影响断点调试或扩展功能，不建议作为长期方案
测试非public成员变量与方法的关键路径
JUnit 4 和 JUnit 5 对测试方法签名有明确限制——@Test方法必须是public void且无参数，因此无法直接测试private、protected或static成员。但可通过合理设计间接覆盖：
- 保护成员（
protected）：让测试类继承被测类，即可在子类中调用保护方法或访问保护字段，无需反射 - 私有成员（
private）：使用Java反射获取Field或Method对象，调用setAccessible(true)打破封装。注意JUnit 5中需配合Assertions.assertDoesNotThrow捕获反射异常 - 静态方法：同样通过反射获取
Method，调用时传入null作为实例参数；若为静态工具类，可直接调用，无需实例化 - 推荐优先测试行为而非实现：例如不直接测某个
private int counter，而是测调用公开方法后其副作用是否符合预期（如日志输出、状态变更、返回值等）
测试类与方法的基本合规性检查
很多看似奇怪的错误（如InvalidTestClassError或initializationError），其实源于最基础的语法和可见性规则未满足：
- 测试类必须声明为
public：即使在同一包内，JUnit运行器也要求显式public class MyTest，默认包权限会导致加载失败 - 测试方法不能是
static、不能有返回值、不能带参数（JUnit 4）、不能是private或protected - 确保导入正确的Assert类：JUnit 4用
org.junit.Assert，JUnit 5用org.junit.jupiter.api.Assertions，混用会编译失败或断言不生效 - 检查依赖完整性：JUnit 4 需要
hamcrest-core支持匹配器，仅加junit-4.12.jar不够；JUnit 5 则需junit-jupiter-api和junit-jupiter-engine成对引入
不复杂但容易忽略
