在 Class 中撰写可测试的单元逻辑

可测试单元逻辑需解耦依赖、职责单一、输入明确、输出可预测：抽象外部依赖为可注入接口，拆分多职责方法为纯函数，避免静态/隐式状态，通过回调或protected方法预留测试钩子。

在 Class 中编写可测试的单元逻辑，核心是把行为从依赖中解耦，让方法职责单一、输入明确、输出可预测。

把外部依赖抽象成接口或参数

数据库、网络请求、时间获取等操作容易让测试变得脆弱或缓慢。应将它们提取为可替换的依赖，例如通过构造函数注入或方法参数传入。

• 避免在方法内部直接调用 new Date() 或 fetch()，改用传入的时间戳或 mock 的响应对象
• 对数据库操作，定义一个 Repository 接口，测试时用内存实现或 jest.fn() 模拟
• 类的构造函数接收依赖，而不是自己创建，便于测试时传入受控的模拟对象

方法只做一件事，且有明确输入输出

一个方法如果同时修改状态、发起请求、格式化数据，就很难单独验证某一部分逻辑。应拆分为小函数，每个函数专注转换或判断。

• 比如 processOrder() 不要包含库存检查、支付调用和日志记录；拆成 canFulfill()、chargePayment()、logSuccess()
• 纯函数优先：给定相同输入，总是返回相同输出，不读写外部变量或 this.state（除非必要）
• 把条件分支逻辑单独抽离为布尔方法，如 isEligibleForDiscount()，方便直接断言 true/false

避免隐藏状态和静态方法

静态方法难以 mock，隐式读取全局状态（如 localStorage、window.location）会让测试环境不可控。

• 把 Date.now() 替换为可注入的 clock.now()，测试时固定返回 1717027200000
• 不要在类方法里直接读取 document.cookie，而是通过配置对象或依赖传入用户上下文
• 静态工具方法若必须使用，确保它无副作用、无外部依赖，否则移到实例方法或独立模块中

为测试预留钩子（Hook）而非暴露私有成员

不必为了测试而把 private 方法改成 public，也不该直接测私有逻辑。可通过参数、回调或事件机制让关键路径可观察。

• 在异步流程中提供 onSuccess 和 onError 回调，测试时传入 jest.fn() 捕获调用
• 用 protected 方法（TypeScript/Java）或约定前缀（如 _validateInput）标识可被子类覆盖的逻辑，测试时继承并 spy
• 对复杂计算，提供 getDebugInfo() 这类非业务方法，仅用于测试断言中间状态