单元/集成/E2E

mermaid flowchart TB subgraph 金字塔 U I E end U --> I --> E

mermaid

flowchart TB Test --> O Test --> C Test --> I O && C && I -.三者缺一就难测.-> Fail

任何一层缺失，单测都会变味。比如事故中的代码：

• 可观测这方面，✓ 返回值能看到；
• 至于可控制。⚠️只能传入「函数自己接受的 amount」，无法控制上游；
• 从可隔离来看，✓ 函数本身没有 IO。

控制力被一层隔板挡住这就是 % 覆盖率仍漏的根源。

与设计耦合的本质

「不可测 = 设计错」是充要条件，这是 OOP 的最硬验收。其实，

至于证明思路。

flowchart LR Untestable --<==> BadDesign Untestable -.充分.-> Bd1 BadDesign -.必要.-> Ut1

• 不可测 → 设计错：不可测代表着无法 mock、无法注入、无法隔离，这必然指向 DIP 或 SRP 等违例。
• 设计错 → 不可测：违反 DIP 的代码 new了具体类，无法替换；违反 SRP 的代码一个方法做太多事情。要 mock 全部副作用，即不可测。

.不可测代码画像

静态方法陷阱

• 调用 OrderUtil.genOrderId 无法 mock，静态调用钉死类型；
• 内部用了 currentTimeMillis 和 Random，返回值每次都不同。

至于修复，把"工具函数"变成实例方法 + 接口：

java public interface OrderIdGenerator { String generate;} public class DefaultOrderIdGenerator implements OrderIdGenerator { private final Clock clock;private final Supplier );assertEquals("u1--",gen.generate);

静态方法是 OOP 的逃生舱口，但每用一次都在牺牲可见度与灵活度。

单例传染性

java public class OrderManager { private static OrderManager INSTANCE = new OrderManager;public static OrderManager getInstance { return INSTANCE;} } public class OrderService { public void place { OrderManager. getInstance.save;// ← 钉死}}

传染怎么发生？怎么说呢，

• OrderService 内部硬编码 OrderManager.getInstance
• 测试时无法替换 OrderManager；
• 要么不做单元，要么使用 PowerMock 改字节码。老实说，

修复这方面。构造器注入，与 DIP 同一道理。不过，

全局时间获取

直接调 System.currentTimeMillis 或 LocalDateTime.now 会让 test flake。把 Clock 抽象出来永远不在业务里直接读现在：

java public class CouponService { private final Clock clock;public CouponService { this.clock = clock;} public boolean isValid { return clock.now.isBefore);}}

@Test void shouldBeValidIfNotExpired { var fixed = Clock.fixed.toInstant);var service = new CouponService;assertTrue(service.isValid(new Coupon(LocalDateTime.of( …,，).toInstant)));}

私有方法依恋

如果私有方法复杂到值得单独写 test，则它应当提取为公共 API 并拆分到新类中。私有方法往往暗示 功能过于集中应改为组合而非深层嵌套。

隐式 IO访问

java public class ReportService { public Report generate { String sql ="SELECT ...";try (Connection c = DriverManager.getConnection) { // ← 隐式 IO …其实，} File template=new File;// ← 隐式 IO ，URL slack=new URL;// ← 隐式 IO ，}}

一次 test 就需启动数据库、读取文件、连 Slack——导致团队放弃单元。只做集成，金字塔倒置，修复请参照 IO边界化。按理说，

.可测设计五原则

依赖注入

说到最基本约束。任何外部依赖都通过构造或 setter 注入，而不是在内部 new。

java // 不要这样class OrderService { // private OrderRepo repo=new MysqlOrderRepo;// ← 钉死 } // 要这样class OrderService { // private final OrderRepo repo;// public OrderService{this.repo=repo;}}

这与 DIP 是同一件事两种视角——DIP 是原则，DI 是落地手段。

时间抽象化

所有业务都注入 Clock 接口，而不是直接调用 Instant.now。再看多语言对照表，

IO边界化

采用 Hexagonal Architecture。主要业务完全通过接口访问外部资源，从而可以使用内存实现进行纯粹 unit test：

mermaid flowchart TB subgraph 内核 D end subgraph 门户 P1 P2 P3 P4 end subgraph 适配器 A1 A2 A3 A4 end D --> P1 & P2 & P3 & P4 P1 -.实现.- A1 P2 -.实现.- A2 P3 -.实现.- A3 P4 -.实现.- A4

至于好处，* 内核不知道 MySQL / Stripe / S3 的存在可使用 InMemory 实现跑全套 unit test；* 每个适配器独立集成，* 换支付提供商只需加一个适配器即可。

副作用集中化

把所有外部改变聚合到一个地方，让 core 方法保持纯粹。例如将订单处理改为决定事件列表，再由另一个 handler 执行动作：

java class OrderProcessor{ /** pure function */ public List // decide without side‑effects */ List.of( new OrderSaved。new EventEmitted,new EmailDispatched,…),new BiReportPushed。new AuditLogged ); } class EventHandler{ public void apply {/* perform side‑effects */}} Unit test 验证 decide 返回预期事件列表即可，无需 mock 多种外部资源；集成再验证 handler 真正执行。

纯函数优先

一样输入永远相同输出，不改外部状态——越高比例越好。写 pure 函数只需几句 assert，即使项目规模大也容易维护。

.测试金字塔

单元/集成/E²E

比例与成本这方面，经典 Mike Cohn 数量比 %Unit＝10%、%Integration＝20%、%E²E＝30%。单位级 ROI 极高 —— 写得快、跑得快、修得快。

倒金字塔反模式产生原因：

• No unit tests due to untestable design.
• Tendency to think E²E 更真实。
• Lack of awareness of unit power.

• CIs run for hours before developers see failures.
• A single change often breaks dozens of E²E tests – root cause unknown.
• Maintenance cost eclipses business value.

.Mock 与 Stub

五种 Test Double 类型