java对象可测试性的核心是降低依赖、提高可控性、明确职责边界；需通过依赖注入（优先构造函数）、接口抽象、封装静态调用、方法职责单一、合理暴露状态等手段实现。
要让Java对象具备良好的可测试性，核心是降低依赖、提高可控性、明确职责边界。不是所有面向对象设计都天然适合测试，关键在于是否便于隔离、替换和验证行为。
用依赖注入替代硬编码依赖
对象内部直接 new 依赖实例（如 new DatabaseConnection()）会阻碍测试——你无法替换成模拟对象（Mock）。应通过构造函数、Setter 或接口参数将依赖“传进来”。
- 优先使用构造函数注入：确保依赖不为空，且对象创建后即处于可用状态
- 依赖声明为接口类型（如 UserRepository），而非具体实现类（JdbcUserRepository）
- 测试时可传入 MockUserRepository 或内存版 InMemoryUserRepository，完全绕过真实数据库
避免静态方法与全局状态
工具类中的静态方法（如 DateUtils.now()、Logger.error()）或单例中的可变状态（如 static Map
- 将静态调用封装进可注入的策略对象（如 Clock、LoggerAdapter）
- 在测试中注入 FixedClock（返回固定时间）或 CapturingLogger（记录日志内容供断言）
- 若必须用静态，考虑使用 PowerMock（不推荐，仅作兜底），但更优解是重构为非静态
让方法职责单一、输入输出清晰
一个方法既查数据库、又发HTTP请求、还写日志，就很难做单元测试——你得 mock 所有外部系统，且断言点模糊。测试友好的方法应“小而确定”。
立即学习“Java免费学习笔记（深入）”；
- 提取副作用操作为独立方法（如 sendNotification()、updateCache()），主逻辑只负责计算和编排
- 返回值尽量具体（如 Optional
、Result ），避免 void + 修改字段或全局状态 - 对边界条件（空参、异常数据）有明确定义，并在测试中覆盖
公开必要的访问点，但不破坏封装
有时需要读取对象内部状态来验证行为（如“是否触发了重试”），但又不想暴露 public 字段或 setter。可通过受保护的 getter、包级可见方法，或提供调试专用的 toString() / toDebugMap() 辅助验证。
- 用 package-private（默认访问级别）方法供同包测试类调用，无需 public 也不需反射
- 为复杂状态提供结构化快照方法（如 getStateSnapshot() 返回不可变 Map），方便 assertEquals
- 避免为测试而加 public setter；若需修改内部状态做测试，说明设计可能耦合过紧，应回顾职责划分
测试友好不是牺牲设计原则，而是让抽象更坚实、边界更清晰。可测试的对象，往往也是高内聚、低耦合、易演化的对象。
