mcpField
T
test-error-states

test-error-states

github.com/reticlehq测试与质量1.3k242 次安装今天更新
代码仓库

关于 test-error-states

用于 Reticle 的技能，可通过模拟网络响应和控制时间测试错误与空状态。它帮助应用开发者在故障条件下验证恢复行为、状态一致性及控制台错误。

主要功能

  1. 01模拟网络响应
  2. 02冻结并推进时钟
  3. 03断言恢复界面与应用状态
  4. 04检查未捕获的控制台错误
  5. 05清除模拟并重置时间

适用场景

  1. 01测试服务器错误后的界面行为
  2. 02验证空响应和格式错误响应状态
  3. 03检查重试与超时行为
  4. 04测试防抖或计时相关界面

安装

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

$npx skills add https://github.com/reticlehq/reticle --skill test-error-states

安装后在 Claude Code 中输入/test-error-states确认已加载。

详细介绍

错误状态从未被运行过

每个应用都有一个从未有人执行过的 catch 块，以及一个从未有人见过的空状态。它们凭空想象而来，未经测试就随应用发布，最终在某个用户倒霉的一天被发现。

Reticle 可以在运行中的应用里强制触发这些状况。还没设置？请按照 reticle 技能操作：它会安装 Reticle，在 init 修改应用文件之前询问用户，并验证一个流程。

开始前请先阅读：网络模拟需要受驱动或已租用的浏览器

reticle_network_mock 会拦截 Reticle 所拥有的浏览器中的请求，常驻 SDK 无法做到这一点。 已连接的标签页若既未运行 reticle drive，也未持有租约，仍会返回 { ok: false, reason: "no-cdp-provider" }。

你可以使用已租用的 Playwright 标签页（reticle_run { tool: "reticle_lease", args: { action: "acquire", url } }），或者将 RETICLE_CDP_URL 指向已启用远程调试的 Chrome：

# macOS — the user runs this once, in their own Chrome
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

RETICLE_CDP_URL=http://localhost:9222 npx @reticlehq/server@latest mcp

如果你既没有租约，也没有受驱动的浏览器，请用一行说明这一点，并仍然提供此技能中的时钟部分：reticle_clock 不需要这些条件。你不能只驱动正常流程，看到它通过，就报告错误处理正常。

强制触发故障

reticle_run({ tool: "reticle_network_mock", sessionId, args: {
  mocks: [{ urlContains: "/api/deploys", status: 500 }],
}})

然后驱动流程，并在操作前说清你预期的恢复方式：

reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "allOf", predicates: [
  { kind: "element", query: { testid: "error-banner" } },
  { kind: "console", level: "error", absent: true },
]}})

注意第二个断言。UI 若只是记录一个未捕获异常就声称“处理”了错误，并不算真正处理。完成后用 { clear: true } 清除模拟，否则之后的每项检查都会基于错误假象运行。

值得按大致的常见故障频率依次强制触发：500、带有真实错误正文的 4xx、空的 200（[]，即空状态）、格式错误的载荷，以及永不返回的请求（一直转不停的加载指示器）。

跳过时间，而不是等待

reticle_run({ tool: "reticle_clock", args: { sessionId, freeze: true } })
reticle_run({ tool: "reticle_clock", args: { sessionId, advanceMs: 5000 } })
reticle_run({ tool: "reticle_clock", args: { sessionId, reset: true } })

自动消失的 Toast、防抖搜索、轮询、会话超时、重试退避。这些情况通常都靠等待来验证，但等待既慢又不稳定。时间断言描述的是机器的行为，因此在你的笔记本电脑上可能通过，在 CI 中却会失败。

冻结时钟，精确推进指定间隔，然后断言结果。在快速笔记本电脑和负载繁重的运行器上，结果都一样。结束时务必执行 reset，否则冻结的时钟会悄无声息地影响之后运行的所有内容。

断言什么

断言是否成功恢复，而不是是否没有崩溃：

  1. 错误已显示给用户：检查具体元素，而不只是确认“页面没有变空白”。
  2. 应用仍可使用：重试有效，表单仍有输入框，导航没有卡住。
  3. 状态如实反映情况：reticle_look { action: "state" } 显示失败，而不是只应用了一半的乐观更新。UI 上回滚了，但存储中的值仍是乐观更新值，这是这里的典型错误，只有读取存储才能发现。
  4. 控制台中没有未捕获的错误。

诚实原则

模拟会改变应用所处的环境，因此在模拟条件下得出的结论只适用于该模拟条件，不代表其他情况。报告通过时，请说明启用的是哪项模拟，并在交还前清除所有模拟、重置时钟。若审计结束时仍将 /api/deploys 固定为 500，就会破坏下一个人的会话，看起来还像真的服务中断。

功能参考：curl https://docs.reticle.sh/capabilities.md。其他内容：curl https://docs.reticle.sh/llms.txt。

评论

支持 Markdown