EP13. "wp-test-strategy 测试策略规划"

• 一个 REST endpoint 改了权限逻辑，你是打算手动点一遍后台确认没坏，还是补一条测试？测试深度该配多深，很多时候是凭感觉，不是凭风险
• wp-test-strategy 是 jorgerosal/wordpress-skills 这套 18 个 skill 里唯一不做代码审查、专门做测试规划的一个，覆盖 unit/integration/E2E 该怎么选、现有测试覆盖率怎么盘点、缺口在哪
• 核心原则一句话：测试深度要匹配风险，测试金字塔的形状要反映这段代码牵涉到的 WordPress 层面有多深
• 前置知识：先看过 EP09「wp-rest-api-development REST API 开发审查」——很多测试规划场景是围绕 REST endpoint、block、后台表单这些其他 skill 审查过的对象展开的

重点内容

这个 Skill 是做什么的

wp-test-strategy 不检查代码对不对，而是回答「这段改动该配什么级别的测试」——判断变更涉及的是纯 PHP 逻辑、WordPress 整合行为、REST/AJAX 流程、block editor 行为、后台流程，还是 WooCommerce 订单/购物车/结账行为，再对照风险给出该测的范围、该用哪个测试层级、什么可以跳过或用别的方式间接覆盖。

适合用在：

• 判断一个功能/修复该加什么测试
• 审查插件或主题里缺失的测试覆盖
• 发布前规划回归测试
• 在 unit、integration、E2E 之间做选择
• 把 block、REST、后台、WooCommerce 行为对应到具体测试类型

不适合用在：

• 不涉及测试决策的纯代码审查
• 只是排查 CI 系统问题
• 单纯的性能基准测试

触发方式

审查流程

1. 识别改动范围：纯 PHP 逻辑、WordPress 整合行为、REST/AJAX 流程、block editor 行为、后台流程、WooCommerce 订单/购物车/结账行为
2. 评估风险：会不会影响用户可见的功能、有没有数据损坏/迁移风险、是不是认证/安全敏感流程、浏览器交互复不复杂
3. 选测试深度：孤立逻辑用 unit test，WordPress API 和数据库状态用 integration test，UI 流程或编辑器交互用 E2E test
4. 输出建议：该测什么、该用哪个层级、什么可以跳过或间接覆盖

测试层级怎么选

快速扫描指令（rg）

# 盘点现有测试覆盖：测试文件/类、PHPUnit 配置、E2E 工具痕迹
rg -n "class .*Test|extends .*TestCase|describe\(|test\(" . -g '*.{php,js,jsx,ts,tsx}'
rg -n "phpunit|tests/bootstrap|WP_UnitTestCase" .
rg -n "playwright|@wordpress/e2e-test-utils|page\.goto|test\(" . -g '*.{js,ts}'

# 找高风险但看起来没有对应测试的地方
rg -n "register_rest_route|add_action|add_filter|wp_ajax_|admin_post_|dbDelta|WC_" . -g '*.php'
rg -n "block.json|edit\(|save\(|registerBlockType" . -g '*.{json,js,jsx}'

各场景该覆盖的测试场景

官方参考文件按四类场景列出建议覆盖点：

• 插件测试：激活/卸载的连带影响、设置保存与消毒流程、hook 驱动的行为
• REST API 测试：权限拒绝的响应、输入校验失败、成功响应的结构
• Block 测试：save/render 行为、属性迁移与 deprecation、编辑器 UI 交互
• WooCommerce 测试：HPOS-safe 的订单访问、购物车/结账回归路径、支付与 webhook 边界情况

实操示例

// ❌ 用 unit test 硬测一段依赖 WordPress 数据库状态的逻辑，
//    要么测不出真实问题，要么被迫大量 mock 核心函数、维护成本很高
class Test_Save_Setting extends PHPUnit\Framework\TestCase {
    public function test_save_setting() {
        // 这里没有真实的 wpdb/option 存储，只能靠 mock，
        // mock 越多，测试跟真实行为的距离越远
    }
}

// ✅ GOOD：涉及 option 持久化、hook 触发，该用 WordPress 的 integration test 基类
class Test_Save_Setting extends WP_UnitTestCase {
    public function test_save_setting_persists_and_sanitizes() {
        update_option( 'myplugin_setting', '<script>bad</script>safe text' );

        myplugin_save_setting( 'myplugin_setting', '<script>bad</script>safe text' );

        $this->assertSame( 'safe text', get_option( 'myplugin_setting' ) );
    }
}

// ❌ REST endpoint 只测「成功路径」，权限拒绝、输入校验失败完全没覆盖
public function test_get_settings_returns_200() {
    $request  = new WP_REST_Request( 'GET', '/myplugin/v1/settings' );
    $response = rest_get_server()->dispatch( $request );
    $this->assertSame( 200, $response->get_status() );
}

// ✅ GOOD：成功、权限拒绝、输入校验失败三条路径都要覆盖
public function test_get_settings_returns_200() {
    wp_set_current_user( $this->admin_id );
    $request  = new WP_REST_Request( 'GET', '/myplugin/v1/settings' );
    $response = rest_get_server()->dispatch( $request );
    $this->assertSame( 200, $response->get_status() );
}

public function test_get_settings_rejects_unauthorized_user() {
    wp_set_current_user( $this->subscriber_id );
    $request  = new WP_REST_Request( 'GET', '/myplugin/v1/settings' );
    $response = rest_get_server()->dispatch( $request );
    $this->assertSame( 403, $response->get_status() );
}

怎么安装

这个 skill 是 wordpress-skills 这个开源仓库（jorgerosal/wordpress-skills）打包的 18 个技能之一，安装一次，18 个技能一起到位，不用逐个装：

Claude Code：

装完重启 Claude Code，进到一个 WordPress 项目里跑 /wordpress-skills:wp-test-review 验证有没有装成功（用 marketplace/submodule 方式装的话，指令前面会带插件命名空间 wordpress-skills:；用「只装这一个 skill」的方式则不带命名空间，直接 /wp-test-review）。

Claude Desktop / claude.ai： 走 Settings → Capabilities → Skills，上传技能文件夹（把 claude-skills/wp-test-strategy 这个文件夹打包上传，里面要包含 SKILL.md）——跟 Claude Code 的 git submodule/marketplace 安装方式不同，Desktop 端是手动上传 UI，装好之后同样能用自然语言或 slash 指令触发。

常见错误

• ❌ 不管什么逻辑一律建议补 E2E 测试——skill 的核心原则是「深度匹配风险」，纯转换/格式化逻辑用 unit test 就够，没必要为了「测得全」硬上浏览器测试，维护成本会失控
• ❌ 现有测试已经覆盖到位，还是习惯性列一堆「建议补充」——skill 明确要求「如果现有测试已经足够，就清楚说明，只提剩余风险或边界情况」，不是每次都要凑出待办清单
• ❌ 把「没测试」直接等同于「有问题」——这个 skill 只做测试规划建议，不是代码正确性审查，缺测试是风险信号，不是它本身证明代码有 bug
• ❌ 只关注功能测试，漏掉无障碍敏感的交互流程该配 E2E——官方场景列表明确把「accessibility-sensitive interaction flows」归进 E2E 该覆盖的范围
• 💡 REST API 测试最容易漏的不是成功路径，是「权限拒绝」和「输入校验失败」这两条——官方场景清单把这两条跟成功响应并列成三个必测点，很多项目只测了成功路径

Sources

官方文档：

1. wordpress-skills（GitHub 仓库）— https://github.com/jorgerosal/wordpress-skills
2. wp-test-strategy SKILL.md — https://github.com/jorgerosal/wordpress-skills/blob/main/claude-skills/wp-test-strategy/SKILL.md