可测试性源于设计：封装边界与解耦协作统一于契约稳定。私有终态、构造注入、接口抽象、行为内聚、事件驱动，共同支撑输入输出可预测、依赖可替换、逻辑可验证、状态可断言。
封装与解耦不是两个独立动作，而是同一设计目标的两面：用封装划定边界，用解耦释放自由。真正可测试的组件，不是靠Mock堆出来的，而是从设计之初就拒绝隐式依赖、屏蔽内部扰动、暴露稳定契约。
私有化状态 + 受控访问 = 可预测的输入输出
测试的本质是验证“给定输入是否产生预期输出”。如果对象状态能被外部随意篡改（比如public字段或无校验setter），测试就失去前提——你无法保证初始状态干净、过程不被干扰。
- 所有业务关键字段声明为private final，构造时一次性注入，杜绝运行中意外变更
- setter方法只保留必要且带业务规则的入口，例如
setOrderStatus(String next)内部校验流转合法性，非法调用直接抛IllegalArgumentException - getter不做简单字段返回，而是封装计算逻辑，如
getEffectiveDiscount()整合会员等级、活动叠加、库存限制等条件，测试只需断言结果，不关心怎么算
依赖抽象化 + 构造注入 = 测试时零污染替换
一个类若在内部new具体实现（如new AlipayClient()）、调用静态工具（如StringUtils.trim()）或持有全局单例，它就已丧失可测性——你无法隔离它与外部环境。
- 把所有协作方定义成接口（
PaymentProcessor、InventoryService），类中只持接口引用 - 依赖全部通过构造器传入，禁止默认构造+后续setter注入；这样每个测试用例可独立传入不同模拟实现
- 连基础能力也抽象化，比如字符串处理封装成
TextNormalizer接口，测试时传new MockTextNormalizer("test")，彻底摆脱对Apache Commons的依赖
行为内聚 + 接口精简 = 单一职责驱动可测粒度
一个方法若同时做校验、调第三方、更新DB、发消息，它就不可测——你得Mock一堆东西，还分不清失败是哪一环的问题。高内聚让逻辑集中，低耦合让协作清晰。
- 每个public方法只做一件事：比如
placeOrder()只负责编排流程，不包含支付细节；支付交给paymentProcessor.process() - 接口只暴露语义明确的方法，删掉
updateStatusAndNotifyAndLog()这类大杂烩方法，拆成confirm()、notifyUser()等小单元 - 包结构按业务域组织（
com.example.order），内部实现类设为package-private，对外仅暴露1–2个门面类，测试范围自然聚焦，不会误测无关模块
事件替代调用 + 状态终态断言 = 解耦后仍可端到端验证
模块间用事件通信后，看似“看不见”下游逻辑，但测试不能因此退化为只测单点。关键在于：不测“怎么通知”，而测“是否触发了该事件”以及“本模块状态是否符合终态”。
- 在测试中捕获发布的事件（如
OrderPlacedEvent），验证其携带数据正确、触发时机合理 - 重点断言本组件的最终状态：订单是否变为
CONFIRMED、库存预占数是否扣减、版本号是否递增 - 下游模块的逻辑由各自单元测试覆盖，你的测试无需Mock通知服务或积分服务，它们只是监听者，不影响你模块的正确性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
