· 测试
单元、集成、E2E：测的不是同一层世界
单元测试、集成测试、E2E 测的不是同一层世界。金字塔为什么下宽上窄。
⬆️
/ E2E \ ← 5~10%
/ 集成 \ ← 20~30%
/ 单元 \ ← 60~70%单元测试：测最小单元
一个函数、一个方法、一个类。外部依赖全部 mock。
- 快，毫秒级
- 挂了就知道是哪一行
- 覆盖正常、边界、异常
- 看不到模块之间对不上的问题
用例从代码结构来：输入、输出、边界值、异常条件。
@Test
void testAdd() {
assertEquals(3, calculator.add(1, 2));
}集成测试：测模块怎么握手
依赖是真的：真数据库、真服务调用。慢，秒级。能抓住「参数格式变了、返回值对不上」这种单测永远测不到的事。坏处是挂了不好定位是哪一层的错。
用例从接口契约来。可以把它想成：把单元测试里的 happy path 去掉 mock，换上真实依赖。
不是所有单测都能升成集成测试。超时、异常注入这些边界，真实依赖上很难稳定复现。
「这个方法调了很多外部方法，它本身就是集成，为什么还要单测？」因为单测里那些依赖是假的，你测的是想象中的它们。集成测的是真实世界里的它们。
E2E：测用户这条路通不通
从用户端走到服务端，整条业务。最慢最贵，一条可能要几分钟；也最接近真实体验。出问题最难定位：前端、后端、数据库、第三方，都可能。
用例从需求来，不是从代码来。只问「用户要做什么」，不问类怎么拆。
所以金字塔才是那个形状：贵的少写，便宜的多写。想用 E2E 覆盖所有分支，账算不平。