mcpField
O
openclaw-testing

openclaw-testing

github.com/openclaw测试与质量393.3k397 次安装今天更新
代码仓库

关于 openclaw-testing

openclaw-testing 是为 OpenClaw 更改制定基于证据的测试与验证流程的 skill，帮助贡献者选择本地检查、远程验证或 CI，并兼顾来源可信度、覆盖率和未解决的问题。

主要功能

  1. 01按更改选择验证方式
  2. 02运行针对性测试与静态检查
  3. 03分类诊断 CI 失败
  4. 04可信来源与状态保护
  5. 05报告覆盖率和验证缺口

适用场景

  1. 01在提交 PR 前验证代码更改
  2. 02诊断 PR CI 失败
  3. 03为平台特性或实时行为选择验证方式

安装

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

$npx skills add https://github.com/openclaw/openclaw --skill openclaw-testing

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

附带文件references/package-and-docker.mdagents/openai.yaml

详细介绍

OpenClaw 测试

证明策略

  • PR CI = 默认的广泛证明。 更改构建成功且针对性测试通过 → 打开 已准备就绪的 PR。CI 会运行广泛测试套件；切勿为了 PR 前的测试套件运行而延迟提交 PR。

  • PR 前进行针对性证明： 对修改涉及的测试运行 pnpm test <file> --maxWorkers=1，并进行针对性的类型检查、Lint 和格式检查。 对于依赖项和当前主机容量均已确认适用的可信、范围明确的工作，优先在本地验证。 本地执行是可选的：针对性命令仍可能加载庞大的编译器依赖图，或扩展到更广泛的测试任务。

  • 审慎选择远程证明。 广泛证明使用 PR CI；Crabbox/Testbox 可用于开销较大的检查、本地主机繁忙或未确认适用、其他操作系统/设备、实时提供方/频道、耗时较长的 E2E 测试或重型基准测试。仅在命令准备就绪且容量能及时获批时才申请资源。如果进入排队状态，只停止由任务占用的资源分配；改用 PR CI 或安全的本地范围。未覆盖的平台特定证明保持待完成状态。切勿强行在繁忙的机器上运行重型任务，也不要串联提供方。选择经验证适用于所选工作负载的最小配置。

  • 切勿只为获得绿色状态而重跑或重新推送。 修复实际失败；在判断红色状态原因前，先查看可用的 CI 失败分类信息。

  • 证明更改后的契约，完成必需的检查门禁，然后结束。仅在输入更改、发生失败或存在明确列出的未解决风险时，才扩大范围或重复运行。

  • 遵循适用范围内的 AGENTS.md；编写/审查测试时，使用 边界指南 和 test-audit。

选择证明方式

  • 根据修改涉及的契约选择证明方式；复用有效的证明（输入有变化或覆盖不足时重新运行）；在用户/主机限制范围内完成工作流要求的检查门禁；报告未运行的检查和覆盖缺口。在可行时，通过真实流程证明用户可见的行为；外部 API 需要实时契约证明；隔离的 mock-Gateway 测试框架可作为有效的频道边界证明。仅文档更改：运行文档健全性检查和 git diff --check。

  • 运行时缺陷：从真实入口复现；重新运行该入口及相关的同类测试。

  • 可信源代码：运行 pnpm changed:lanes --json、针对性测试及针对性的类型检查/Lint/格式检查；pnpm check:changed 是可选的智能本地检查。

  • 公共 SDK/插件契约：测试有代表性的使用者，而非扫描所有插件。

  • 构建输出、延迟导入、软件包边界：包含 pnpm build。

  • 工作流：运行 git diff --check 和 pnpm check:workflows。

  • 仅文档更改：运行相关文档/链接/格式检查和 git diff --check；不运行运行时测试。

  • 按需查阅：本地命令、 Crabbox、OpenClaw 远程设置、 软件包/Docker 证明、 发布 CI、 插件发布矩阵、 Docker 编写指南、频道技能/ Control UI E2E。

  • 隔离的 mock-Gateway 测试框架可作为有效的频道边界证明；注明实时测试缺口。在可行时，通过真实流程证明用户可见的行为；外部 API 需要实时契约证明。进行实时频道或原生应用相关工作时，阅读适用范围内的频道/平台指南。Telegram 相关声明必须通过 使用 Convex 租赁凭据的 Test Server userbot 证明。 平台相关声明必须提供真实设备证据；macOS 权限证明必须使用稳定的签名应用。

  • 发布证明：保留候选版本/Tooling 的 SHA；绝不授予发布权限。

源码与状态边界

  • 切勿在本地执行不受信任的贡献者／分支代码、包装器或配置。 使用无密钥的分支 CI，或通过 Crabbox 直接访问经过清理的 AWS；切勿使用注入凭据的 Testbox。执行需要凭据的操作：必须经审查并获得维护者批准；切勿向不受信任的租约注入凭据。
  • 使用隔离状态和空闲端口。未经针对具体任务的明确批准，切勿重启、编辑或测试运维人员的 Gateway／真实数据。保留无关进程和共享依赖安装。
  • 并发运行测试／检查命令时：使用不同的 OPENCLAW_VITEST_FS_MODULE_CACHE_PATH 值，或串行运行；检查命令也可能运行 Vitest。只能使用仓库包装器，切勿直接运行原始 Vitest。准备好的链接工作树：node scripts/run-vitest.mjs <file> --maxWorkers=1 可避免 pnpm 协调；PR CI 会运行范围更广的检查。

CI 失败

  • PR CI 失败 → pnpm test:ci-failed <pr>；查看分类结果：既有／新增／未知。
  • 修复新增失败；调查未知失败 → 运行 pnpm test:ci-failed <pr> --run，直到所选测试在本地通过 → 推送一次。
  • --run 会启用 OPENCLAW_NODE_TEST_PLAN_CONTINUE_ON_FAILURE=1：在所选配置中收集普通失败，但基础设施失败仍会中止；手动重新运行聚焦测试时，也使用相同的启用选项。
  • 既有失败：参见失败表格落地规则。匹配签名 ≠ 仅凭作业名称归因。
  • 切勿通过 gh run rerun 追求全绿；修复 CI 时切勿在本地运行完整测试套件。
  • 将诊断与确切的 SHA 和作业绑定。只获取一次失败日志；优先依据确切的运行／作业状态，而非过时的 PR 汇总信息。
  • 区分产品、测试框架、基础设施、凭据以及被后续运行取代而取消的情况。快照在 macOS 上通过、在 CI 中失败：先复现 Linux／Node 字节差异，再重新生成。
基线和预期失败例外

仅当每项狭义基线、快照、忽略和预期失败例外都已根据源码核实，且 PR 记录了原因时（例如，升级快照中由工具维护的元数据，而用户数据保持不变），实施者才能自行决定是否采用这些例外。切勿掩盖真实回归或用户数据变更。宽泛或未经核实的例外需要批准。仅精确缩减的阈值更新属于维护工作。

测试失败政策
  • 失败即缺陷。进行有限的复现尝试（首先保持相同的分片顺序）；确定负责人；修复产品、测试夹具、共享状态或顺序方面的缺陷。
  • 已证实修复有效：添加回归测试；适用时注明其他负责人的修复。
  • 无法确定／完成安全修复：在 PR 中记录原始失败、尝试、证据和不确定性；按正常 CI／审查门槛继续。
  • 单独存在的未解决失败既不阻止合并，也不要求额外批准。重放通过 ≠ 已证实修复。
  • 切勿通过重试、延长超时、削弱断言、扩大模拟范围或更改基线来掩盖失败。

评论

支持 Markdown