mcpField
P
plan-tests

plan-tests

github.com/igmarin测试与质量2845 次安装4 周前更新
代码仓库

关于 plan-tests

Plan Tests 是用于规划 Rails 测试的 skill，帮助选择最能验证行为的边界。它将变更类型对应到 spec 类型和路径，并要求先写最小失败示例，再进行设计检查。

主要功能

  1. 01按变更选择合适的 spec 类型
  2. 02建议常规 spec 路径
  3. 03从一个最小失败示例开始
  4. 04验证失败原因与测试边界
  5. 05提供结构化测试计划格式

适用场景

  1. 01规划 API 契约变更的测试
  2. 02选择异步任务行为的覆盖方式
  3. 03测试引擎路由或宿主集成
  4. 04修复前复现缺陷

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/igmarin/rails-agent-skills --skill plan-tests

安装后在 Claude Code 中输入/plan-tests确认已加载。

附带文件assets/first_slice_template.md

详细介绍

规划测试

快速参考

变更类型首选 spec路径原因
API 契约、参数、状态码、JSON 结构Request specspec/requests/验证真实的 HTTP 契约
内聚记录或值对象上的领域规则Model specspec/models/对领域行为提供快速反馈
跨协作者的多步骤编排Service specspec/services/聚焦工作流边界
入队/运行/重试/丢弃行为Job specspec/jobs/直接捕获异步语义
关键的 Turbo/Stimulus 或浏览器可见流程System specspec/system/仅当浏览器交互是真正的风险时使用
引擎路由、生成器、宿主集成Engine specspec/requests/ 或引擎路径普通应用 spec 会遗漏引擎接线 — 参见 test-engine
Bug 修复复现 spec观察 bug 的位置验证修复并防止回归

HARD-GATE

CHECKPOINT: Test Design Review

1. Present: Show the failing spec(s) written
2. Ask:
   - Does this test cover the right behavior?
   - Is the boundary correct (request vs service vs model)?
   - Are the most important edge cases represented?
   - Is the failure reason correct (feature missing, not setup error)?
3. Confirm: Proceed after the test design meets the accepted requirements and RED is observed.

核心流程

从价值最高的边界开始，以最少的必要设置验证行为。

步骤
  1. 命名行为： 说明要验证的用户可见结果或不变量。
  2. 定位边界： 确定行为首先在何处被观察到 — HTTP 请求、服务入口点、模型规则、作业执行、引擎集成或外部适配器。使用快速参考表将变更类型映射到正确的 spec 类型。
  3. 编写一个失败示例： 保持最小化；一个示例足以打开关卡。将其他用例列为后续覆盖。
  4. 建议路径： 使用常规 Rails 约定命名可能的 spec 路径（例如 spec/requests/...、spec/services/...、spec/jobs/...、spec/models/...）。
  5. 运行并验证： 确认失败是因为行为缺失，而不是因为设置损坏。
  6. 交接： 继续使用适合该切片的技能 — write-tests 用于通用 spec 编写，test-service 用于服务层覆盖，或 test-engine 用于引擎集成。
示例
良好：新的 JSON 端点
# Behavior: POST /orders validates params and returns 201 with JSON payload
# First slice: request spec
# Suggested path: spec/requests/orders/create_spec.rb

RSpec.describe "POST /orders", type: :request do
  let(:user) { create(:user) }
  let(:valid_params) { { order: { product_id: create(:product).id, quantity: 1 } } }

  before { sign_in user }

  it "creates an order and returns 201" do
    post orders_path, params: valid_params, as: :json
    expect(response).to have_http_status(:created)
    expect(response.parsed_body["id"]).to be_present
  end
end
良好：新的编排服务
# Behavior: Orders::CreateOrder validates inventory, persists, and enqueues follow-up work
# First slice: service spec
# Suggested path: spec/services/orders/create_order_spec.rb

RSpec.describe Orders::CreateOrder do
  subject(:result) { described_class.call(user: user, product: product, quantity: 1) }

  let(:user)    { create(:user) }
  let(:product) { create(:product, stock: 5) }

  it "returns a successful result with the new order" do
    expect(result).to be_success
    expect(result.order).to be_persisted
  end
end
陷阱
陷阱应对方法
因为简单而从 PORO spec 开始简单 ≠ 高信号 — 选择能验证真实行为的边界
在运行任何 spec 之前编写三种 spec 类型选择一个切片，运行它，验证失败，然后继续
对所有内容默认使用一种 spec 类型将 spec 类型与真正风险所在的层匹配（HTTP、领域、异步、浏览器）
过早跳到 system spec保留给较低层无法验证的关键浏览器流程

扩展资源（渐进式披露）

仅当需要其特定内容时才加载这些文件：

  • assets/first_slice_template.md — 在记录测试计划时使用；提供用于行为、边界决策、打开关卡 spec 和后续覆盖的结构化模板

输出风格

完成测试规划时，生成简要的结构化摘要，并使用 assets/first_slice_template.md 填充完整计划。摘要必须涵盖：

  • 行为 — 正在验证的用户可见结果
  • 首个切片 — spec 类型、文件路径和边界理由
  • 打开关卡 — 预期的 RED 失败消息，以及确认失败原因是“功能缺失，而非设置错误”
  • 后续覆盖 — 从初始关卡推迟的其他用例的要点列表
  • 设计检查点 — 确认行为、边界、边缘用例和失败原因均已验证

评论

支持 Markdown