json测试

昨晚我熬夜调试一个接口，测试对方返回的测试JSON里有个字段叫`expire_time`，我按惯例写成`expireTime`，测试结果后端直接甩过来一个400。测试那一刻我盯着屏幕，测试突然意识到——JSON这东西，测试看似只是测试键值对的堆砌，实则是测试一张写满潜规则的脸。

先别急着谈什么数据交换格式的测试宏大意义。就说最基础的测试：键名到底该用驼峰还是下划线？我见过前端团队和后端团队为此开了三次会，最后项目经理拍板“统一用下划线”，测试结果前端老大私下跟我抱怨：“这玩意儿在JavaScript里写起来跟踩地雷似的测试。”你没法说谁对谁错，测试因为JSON自己根本没规定键名风格，测试它只认双引号包裹的测试字符串。但正是这种“不规定”，让每个团队都活成了自己的孤岛。

更有意思的是类型问题。上周我同事从第三方平台拉数据，文档上明明白白写着`"count": 5`，结果实际返回是`"count": "5"`——字符串套了个数字的皮。他拿这个值去做加法，页面直接显示`"55"`，用户差点投诉数据造假。这种坑，JSON不管，它连注释都不支持，更别说类型校验了。你只能自己写个schema，或者靠运行时疯狂`typeof`，活像在垃圾堆里找金子。

再说个冷门的细节：JSON里允许嵌套，但嵌套深度一旦超过三层，人眼基本就废了。我见过一个配置接口，返回结构是`data.list.items[].specs.details[].meta`，整整六层。前端拿到手要遍历，后端要维护，中间任何一层字段名写错，排查起来比找丢失的袜子还难。有人提议用JSON Pointer，可那东西写出来像加密电报，`/data/list/0/specs/details/1/meta`，谁看谁头疼。

有时候我甚至觉得，JSON就像个脾气古怪的老房东——它不拒绝你住进来，但水管坏了它不管，墙皮掉了它不修，你只能自己带工具箱。可偏偏全世界都在用它，从浏览器到服务器，从物联网设备到AI接口。你说气不气？但转念一想，正是这种极简到近乎野蛮的设计，才让它活了二十年还没被替代。XML太重，YAML太松，Protobuf太严，只有JSON，懒散地躺在中间，让所有人恨着却又离不开。

所以每次写JSON测试用例，我都当是在跟一个情绪不稳定的朋友打交道：先测空对象，再测超长字符串，接着塞个负数进去，最后故意把键名拼错。你永远不知道它下一秒会给你什么惊喜——是解析报错，还是静默地返回一个`null`，让你在业务逻辑里慢慢中毒。活到这份上，我只能说：JSON测试不是验证数据格式，而是验证你对这个混乱世界的容忍度。