测试源码

凌晨两点，测试源码我盯着屏幕上那行报错，测试源码咖啡杯沿已经结了一圈干掉的测试源码渍。`Uncaught TypeError: Cannot read property 'length' of undefined`。测试源码这行字我见过不下百次，测试源码每次出现都像有人往我后脑勺泼了杯冰水。测试源码可这次不一样——我明明在调用前检查过那个变量，测试源码断点也打了，测试源码console.log也塞了，测试源码它就是测试源码undefined。

后来我发现，测试源码问题出在一行看似无害的测试源码代码上。`const data = res.data || { }`。测试源码这行保护性写法没错，测试源码错的测试源码是我后续用了`data.items.length`，而`data`确实是空对象，但`data.items`压根不存在。真讽刺，我加那行保护是为了防后端返回空值，结果自己给自己挖了坑。

干这行越久越觉得，测试源码这事儿，测的不是代码，是人的思维盲区。上个月我们组修一个支付回调的bug，现象是偶发性的订单状态不更新。同事查了三天，最后发现是Redis缓存和数据库之间没有做原子性操作。代码逻辑单独看每一步都是对的，串起来就出鬼。

还有个更邪门的。有次线上环境某个接口响应慢，压测工具显示TP99要2秒。我们优化了SQL、加了索引、上了缓存，指标纹丝不动。最后用tcpdump抓包才发现，是运维在负载均衡器上配了个超时重试，每次请求都发了两遍到后端。第一遍慢，第二遍快，但响应时间取的是第一遍的。你说这算谁的锅？代码里压根没这段逻辑。

我现在的习惯是，每写一段新功能，先不急着跑通happy path。我会故意把输入改成极端值——空数组、超大数字、负数、字符串里的特殊字符。甚至会把后端接口直接mock成返回500，看前端会不会崩溃。这么干多了，反而比写单元测试更容易暴露问题。单元测试是理想国，真实世界全是脏数据。

上礼拜我review一个新人的代码，他写了个工具函数，参数是对象数组，里面有个字段叫`price`，他直接拿来做算术运算。我问他如果`price`是字符串"12.5"怎么办？他愣了一下，说前端表单已经做了校验。我让他去翻一下后端文档，那边返回的`price`字段类型标注是`number`，但实际线上偶尔会带个空格。后来他加了`Number()`强转，问题解决。

这种事儿说多了都是泪。测试源码，说白了就是跟不确定性搏斗。你永远不知道用户会怎么操作，后端会返回什么，网络会怎么抖动。唯一能做的，就是在每个入口都设卡，每个边界都试探。代码里那一条条`if`判断，不是写给人看的，是写给未来那个凌晨两点的自己。

现在我的编辑器里常年开着一个文件，叫`edge-cases.js`，里面全是这些年踩过的坑的复现用例。每次新项目启动，我先把这些case跑一遍，能过再写业务逻辑。有人说我太谨慎，可我觉得，干这行，谨慎就是专业。