PHP JSON单元测试方法及实践操作

本文深入探讨了PHP中JSON解析函数的单元测试最佳实践，强调应聚焦于测试开发者封装的业务逻辑而非PHP内置的json_decode函数本身；通过assertEquals直接比对解码后的PHP数据结构，全面覆盖空字符串、BOM头、中文乱码、非法编码、超长嵌套等关键边界场景，并指出assertJsonStringEqualsJsonString在自定义类型转换场景下的局限性；同时详解了如何通过依赖注入、Mock解析器或反射手段可靠模拟解析失败，确保错误处理健壮性，并特别提醒注意测试文件UTF-8无BOM编码、多PHP版本下JSON标志位（如JSON_INVALID_UTF8_IGNORE）的兼容性差异，帮助开发者写出稳定、可移植、真正反映业务意图的高质量测试用例。

怎么用 PHPUnit 测试一个解析 JSON 的 PHP 函数

直接测 json_decode() 返回值是否符合预期，而不是测 PHP 自带函数本身。重点是你自己写的封装逻辑——比如默认返回空数组、过滤非法字符、兼容非 UTF-8 编码等。

常见错误现象：json_decode() 返回 null 但没检查 json_last_error()，导致测试用例通过了，实际运行却静默失败。

• 写测试前先确认被测函数是否做了错误处理（比如抛异常 or 返回 false）
• 用 json_encode() 构造合法/非法输入，别手写 JSON 字符串——容易漏转义
• 测试必须覆盖：空字符串、null、含 BOM 的 UTF-8、中文乱码字节流、超长嵌套对象

为什么 assertJsonStringEqualsJsonString 不够用

这个断言只比对 JSON 字符串结构等价性，不反映你的真实业务逻辑。比如你的函数把 "123" 转成整数 123，它会认为和原始字符串不相等，但这是你设计的转换行为。

更可靠的做法是：先用 json_decode($input, true) 解析，再用 assertEquals() 比较 PHP 数组结构。

• 避免用 assertJsonStringEqualsJsonString() 测自定义转换逻辑
• 如果函数返回对象（json_decode($s, false)），就用 assertEquals() 比较 stdClass 属性
• 注意浮点数精度：JSON 中 1.0 和 1 在 PHP 数组里都是 int，但严格比较可能失败

测试含中文或特殊字符的 JSON 输入时要注意什么

PHP 的 json_decode() 要求输入是 UTF-8 编码，否则直接返回 null。很多测试用例在 IDE 里编辑时默认保存为 GBK 或 UTF-8 with BOM，本地跑得通，CI 上就挂。

• 测试文件本身必须存为 UTF-8 without BOM（VS Code / PHPStorm 右下角可查）
• 不要用 file_get_contents() 读取含中文的 fixture 文件后直接传给被测函数——先 mb_convert_encoding($s, 'UTF-8', 'auto')
• 用 json_last_error_msg() 断言错误信息，比只断言 null 更能定位问题根源

如何模拟 json_decode 失败的边界场景

不能只靠构造非法 JSON 字符串来触发失败，因为有些非法输入（如超深嵌套）在不同 PHP 版本中表现不一致，甚至被 silently 截断。

推荐做法：用 ReflectionClass 临时替换 json_decode 行为，或者直接在被测函数里允许传入 mock 解析器（依赖注入）。

• 简单方案：在函数签名加一个可选参数 $decoder = null，测试时传入 function() { return null; }
• 复杂但干净：把 JSON 解析抽成独立 service 类，用 PHPUnit 的 createMock() 替换
• 别用 override_function() 或 runkit —— Xdebug 关闭时不可用，且与 PHP 8+ 兼容性差

最常被忽略的是：没测 json_decode($s, true, 512, JSON_INVALID_UTF8_IGNORE) 这类标志位组合在不同 PHP 小版本间的差异。特别是 JSON_INVALID_UTF8_IGNORE 在 7.2+ 才可用，而 CI 环境可能混着多个版本。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PHP JSON单元测试方法及实践操作》文章吧，也可关注golang学习网公众号了解相关技术文章。