在类中编写可测试单元逻辑的实用方法

写可测试的单元逻辑，说到底就一句话：把行为从依赖里拆出来，让每个方法只干一件事，输入清楚、输出靠谱。

不少团队在写 Class 时，一上来就把数据库、网络请求、时间戳全塞进方法里，测试时要么跑不动要么慢得要命。怎么破？下面几个原则是经过大量项目验证的“解药”。

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

数据库调用、网络请求、甚至 new Date() 这种“时间获取”，都是测试的拦路石。它们让逻辑与环境强绑定，一跑测试就得搭真实环境，脆弱又缓慢。更务实的做法是：把这些依赖设计成可替换的接口，通过构造函数注入或方法参数传进来。

• 别再在方法里直接 new Date() 或 fetch() 了，改成接收一个时间戳参数或一个 mock 响应的对象。
• 对数据库操作，先定义好 Repository 接口，测试时扔进一个内存实现或者 jest.fn() 就行。
• 构造函数就把依赖收进来，而不是在方法里自己 new 出来——这样测试时你就能递过去一个完全可控的假对象。

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

一个方法如果同时干三件事——改状态、发请求、格式化数据——那要验证其中任何一部分都得跑完整条链路，出了问题也搞不清是哪一环崩了。不如拆成多个小函数，每个只做一次转换或判断。

• 比如 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 或 Ja va 中）或约定前缀（比如 _validateInput）标识可被子类覆盖的逻辑，测试时继承并 spy 即可。
• 对于复杂计算，可以额外提供 getDebugInfo() 这类非业务方法，只用于测试时断言中间状态，不影响主流程封装。

说白了，可测试代码不是靠“事后补测试”堆出来的，而是在写第一行逻辑时就设计好隔离和接口。遵循这些原则，测试不再是负担，反而成了代码信心的翻跟斗。