转推分享写测试的六条原则:测行为、用 BDD、禁 mock、重 E2E、覆盖率与 lint 化。
RT @yaogangqiang: 上一条说，只靠测试不能保证软件质量。这条先聊也应该怎么写测试，因为这是基础。下次聊关键设计，以及 review 应该看什么。
针对业务项目，我的理解大概是这么几条：
1 测试行为，不测试实现。比如重复下单不会重复扣款，而不是某个方法调用了几次。业务没变，重构一下测试就碎一地，那多半写错了。AI 特别容易写这种测试。
2 用 BDD，先写验收场景，再写代码。测试描述统一用 user 开头，用 Given / When / Then 描述，用户和 PM 也能看懂。别让 AI 写完代码，再照着自己的实现证明自己没错。
3 禁止 mock。Redis、PostgreSQL 能用真的就用真的，外部系统不好接就注入 fake，但要校验它和真实系统的契约。时间逻辑用 fake timer，别 sleep 几秒再祈祷。AI 真的太喜欢随手 mock 了。
4 我倾向大部分写 E2E，从用户入口走到可见结果，外部依赖可以 fake，实在不合适再写其他测试。测试多了就分级，按改动和依赖关系精准测试，定期完整跑。别改两行代码，等 CI 半天。
5 前面做好了，再看分支覆盖率，先定个 90%。但重点是剩下的为什么没测，尤其是失败路径，别让 AI 为了凑数字再写一堆垃圾测试。
6 前边的规则尽量都写成 lint
针对业务项目，我的理解大概是这么几条：
1 测试行为，不测试实现。比如重复下单不会重复扣款，而不是某个方法调用了几次。业务没变，重构一下测试就碎一地，那多半写错了。AI 特别容易写这种测试。
2 用 BDD，先写验收场景，再写代码。测试描述统一用 user 开头，用 Given / When / Then 描述，用户和 PM 也能看懂。别让 AI 写完代码，再照着自己的实现证明自己没错。
3 禁止 mock。Redis、PostgreSQL 能用真的就用真的，外部系统不好接就注入 fake，但要校验它和真实系统的契约。时间逻辑用 fake timer，别 sleep 几秒再祈祷。AI 真的太喜欢随手 mock 了。
4 我倾向大部分写 E2E，从用户入口走到可见结果，外部依赖可以 fake，实在不合适再写其他测试。测试多了就分级，按改动和依赖关系精准测试，定期完整跑。别改两行代码，等 CI 半天。
5 前面做好了，再看分支覆盖率，先定个 90%。但重点是剩下的为什么没测，尤其是失败路径，别让 AI 为了凑数字再写一堆垃圾测试。
6 前边的规则尽量都写成 lint