标签： 自动化测试
-
在使用 AI 批量补全 WordPress 历史文章摘要之前，我先建立了一套只读格式审计管线，用于受控导出文章、识别 Classic Editor、Gutenberg、SyntaxHighlighter 和 Code Block Pro 等历史格式，并进行风险分类与候选筛选。项目已完成 3 条、20 条和 100 条生产样本验证，143 个自动化测试全部通过，并以中英文文档形式公开到 GitHub。当前阶段不调用 AI，也不写回 WordPress，重点是先明确格式边界、数据安全和失败保护，为后续长期运行的摘要补全流程建立可靠基础。
-
在排查 SlyTranslate、GLM-5.2、Polylang、PublishPress Series 与 W3 Total Cache 之间的兼容问题时，传统的“生成命令—手动执行—复制结果—继续分析”方式逐渐变得低效，长时间会话也开始造成浏览器卡顿。本文结合真实的 WordPress 生产环境修复过程，记录如何将源码读取、Hook 定位、最小 Diff、PHP 测试、SHA256 校验、文件备份、原子部署、现有数据修复和回滚验证交给 Codex 执行，同时由人工控制修改范围、架构方向和生产风险。实践表明，Codex 适合承担已经明确的代码分析与部署任务，但是否修改某个插件、是否接受新方案、是否存在功能重复，仍需要人工判断。
-
编写 Lighthouse 5 自动化测试用例时，PhpStorm 无法自动完成且找不到 assertJson 声明。经排查，$response 对象实际路径显示为 \Illuminate\Foundation\Testing\TestResponse，而正常项目应为 \Illuminate\Testing\TestResponse。确定问题由 Laravel Framework 6.20.44 与 nuwave/lighthouse v5.36.0 版本不匹配导致。执行 Composer 命令将 nuwave/lighthouse 回退至 v4.10.2 后，代码提示恢复正常。
-
在编写 Lighthouse 5 自动化测试用例时，将单个测试方法拆分为两个后运行报错，提示 Call to undefined method Illuminate\Support\Facades\Config::set()。排查发现第二个方法中应用实例已不复存在。参考 PHPUnit 文档后，在 phpunit.xml 中设置 processIsolation 为 true，或者在运行测试时添加 –process-isolation 选项，即可实现进程隔离并解决该问题，使测试通过。
-
编写 Lighthouse 5 的自动化测试用例时，针对运行 GraphQL Query API 返回 200 的场景，重点测试 themeAssets 字段的响应。由于字段值无法预测且不准备插入新记录，因此仅验证字段是否存在。通过基于 $response->assertJsonStructure 断言响应具有给定的 JSON 结构来达成目的，最终运行测试并通过。