单元测试通过主动模拟非法调用（如反射访问default/private成员）来验证封装边界，成功越界即断言失败；需覆盖包私有、模块化隔离及protected继承契约，并避免测试自身破坏封装。
单元测试本身不能“限制”外部包调用，它不参与运行时访问控制。它的作用是验证——在测试中主动尝试非法调用，一旦成功就立刻失败，从而倒逼开发者守住封装边界。关键不是让测试“拦住”别人，而是让测试“揪出”越界行为。
用测试模拟跨包非法访问场景
Java 的 default（包私有）和 private 成员在编译期就被拒绝跨包访问，但测试需覆盖那些“看似可行实则违规”的灰色地带：
- 把待测类放在
com.example.core包，测试类放在com.example.integration包（不同包） - 尝试用反射强行调用
default方法：clazz.getDeclaredMethod("helperProcess")→method.setAccessible(true)→method.invoke(obj) - 若该方法本意是包内协作工具，测试中反射调用成功，就应 显式断言失败：
assertThrows<illegalaccessexception>(...)</illegalaccessexception>或检查是否抛出InaccessibleObjectException（模块化环境下）
测试驱动的封装契约
为每个非 public 成员定义明确的“可见性契约”，并在测试中固化：
-
private void normalizeInput(String s)→ 测试只允许被本类其他public方法间接触发，禁止任何反射直调 -
String getInternalCacheKey()（default）→ 测试中新建一个同包外的类去new它并调用，应编译失败；若用反射绕过，测试应捕获异常并失败 - 对
protected方法，测试要覆盖子类继承后的合法调用路径，同时验证非子类跨包调用必然失败
结合模块化强化测试防线
在启用 JPMS（module-info.java）的项目中，测试可验证模块边界是否真正生效：
- 确保敏感包如
internal.crypto未出现在exports中 - 写一个测试模块
test.malicious，尝试requires主模块后直接 import 并 new 内部类 —— 应编译失败或运行时报NoClassDefFoundError - 用
--illegal-access=deny启动测试 JVM，使反射调用未导出包内default成员直接抛InaccessibleObjectException，测试捕捉该异常即证明隔离有效
避免测试成为封装漏洞放大器
测试代码本身不能破坏设计原则：
- 不要在测试里写
setAccessible(true)去“方便”验证逻辑——这等于主动拆墙 - 不为
private字段写 getter 测试；验证应通过 public 行为间接体现（例如：调用save()后检查日志、状态变更或副作用） - 使用
@TestInstance(TestInstance.Lifecycle.PER_CLASS)配合私有构造器测试单例，而非暴露public构造器供测试滥用
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
