191、测试驱动排错：先写一个失败的测试，修复 bug，让测试永远守护你

191、测试驱动排错：先写一个失败的测试，修复 bug，让测试永远守护你上周五晚上十一点，我盯着屏幕上那个诡异的JSON解析错误，头皮发麻。生产环境上一个用户提交的数据导致整个API接口返回500，日志里只有一行“Expecting value: line 1 column 1 (char 0)”。直觉告诉我这是空字符串被传进来了，但翻遍代码，发现所有入口都做了非空校验。更诡异的是，本地复现不了——同样的数据，本地跑得好好的，上了服务器就炸。这种“幽灵bug”最折磨人。我泡了杯浓茶，决定换个思路：不急着修，先写个测试，让bug现形。从“修bug”到“抓bug”的思维转换大多数人的第一反应是直接改代码。看到报错，定位到那行，加个if判断，搞定。但这样修bug有个致命问题：你只修了当前这个场景，下次换个姿势进来，照样炸。我当时的做法是：打开测试文件，写了一个测试用例，专门模拟那个空字符串场景。跑一下——测试通过。等等，测试通过？这说明我的代码根本没处理这个情况，但测试却认为它是正确的。问题找到了：测试覆盖不全。# 别这样写——测试太乐观了deftest_parse_user_data