2
1
0
上一条说，只靠测试不能保证软件质量。这条先聊也应该怎么写测试，因为这是基础。下次聊关键设计，以及 review 应该看什么。
针对业务项目，我的理解大概是这么几条：
1
时政
(
twitter.com
)
由
Gangqiang Yao
提交
上一条说，只靠测试不能保证软件质量。这条先聊也应该怎么写测试，因为这是基础。下次聊关键设计，以及 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
点击图片查看原图
Markdown支持
评论加载中...
您可能感兴趣的：
1
80
79
79
3
150
149
149
9
241
240
240
10
301
300
300
11
916
915
915
12
620
619
619
17
292
291
291
20
239
238
238
22
395
394
394
