后端前端【免费下载链接】remark42comment engine项目地址https://gitcode.com/gh_mirrors/re/remark42点击查看免费下载remark42 是一个自托管的评论引擎其核心产品形态是嵌入第三方页面的 Web Widget。e2e/目录下的端到端测试套件以下简称“套件”用真实的浏览器驱动这个 Widget验证其在登录、评论、订阅、跨域嵌入、TLS 与第三方 Cookie 等场景下的真实行为。本指南以 e2e/README.md 为主体结合仓库中的 Makefile、compose-e2e-test.yml、e2e/coverage.sh 与 e2e/ 下各测试文件源码完整讲解套件的运行方式、双端覆盖率采集原理、测试堆栈构成、失败排查手段以及测试设计中的关键约束。读完本文你可以独立在本地跑通并扩展这套浏览器级验证体系也能理解其背后的工程决策。套件概览用 playwright-go 驱动真实浏览器套件通过 Go 绑定github.com/mxschmitt/playwright-go驱动真实浏览器针对从当前检出checkout构建的 remark42运行测试。模块声明为github.com/mxschmitt/playwright-go尽管其仓库已迁移至 playwright-community 组织不要将导入路径改写为仓库 URL携带匹配路径的版本无法安装其浏览器驱动。该模块位于 e2e/go.mod依赖 playwright-go 与 testify。从源码结构看套件覆盖的功能面相当完整e2e/e2e_test.go 的包注释列出了各文件职责e2e/auth_test.godev OAuth2、匿名、邮箱登录e2e/comment_test.go发帖、回复、编辑、删除e2e/vote_test.go投票及失败路径e2e/thread_test.go排序与折叠持久化e2e/iframe_test.goiframe 的配色方案与揭示握手e2e/https_test.goTLS 下的 Widget 行为e2e/telegram_test.go 与 e2e/telegramsub_test.goTelegram 认证与订阅另有 e2e/subscribe_test.go、e2e/profile_test.go、e2e/widgets_test.go 等覆盖订阅、个人评论、最近评论与计数器等 Widget 形态。前置条件运行套件需要满足以下条件Docker 与 Compose套件通过 shell 调用docker compose拉起测试堆栈与 e2e/go.mod 匹配的 Go 工具链首次运行需要网络Playwright 驱动与浏览器会下载到用户缓存目录Linux 为~/.cache/…macOS 为~/Library/Caches/…这是冷启动最慢的部分make e2e-cover额外需要前端依赖Widget 覆盖率报告使用nyc需先在frontend/apps/remark42下执行pnpm install普通的make e2e不需要。运行方式最简运行make e2e对应的目标在 Makefile 中定义为e2e: cd e2e go test -tagse2e -count 1 -parallel 4 -timeout 20m ./...套件在未发现已有堆栈应答时会自行通过 Compose 拉起堆栈运行结束后再拆除。若希望多次运行间保留容器可先手动启动make e2e-up make e2e make e2e-down其中e2e-up会先执行 e2e/tls/generate.sh 生成 TLS 证书并以与套件自启堆栈相同的方式打上源码摘要stampe2e-down执行docker compose -f compose-e2e-test.yml down -v-v会连同命名卷一起删除保证下一次运行从空站点开始。并行与隔离默认运行同时放行四个顶层测试。每个浏览器上下文browser context都有隔离的 Cookie、存储、唯一线程 URL 和固定的测试专用客户端 IP因此后端的按 IP 控制限流、投票去重只作用于单个读者。Telegram 用例共享一个 bot stub最近评论last-comments用例读取站点级 feed因此这两组测试保持串行。运行单个测试从e2e/目录运行Compose 文件路径相对该目录cd e2e go test -tagse2e -run TestComment_ReplyNestsUnderItsParent -v ./...所有测试文件都以//go:build e2e构建标签保护见 e2e/e2e_test.go 首行因此它们不会进入普通的go test ./...不加-tagse2e就什么都不会运行。可视化运行与环境变量make e2e-ui以可见浏览器运行并保留堆栈e2e-ui: cd e2e E2E_HEADLESSfalse E2E_KEEP1 go test -tagse2e -count 1 -parallel 4 -v -timeout 20m ./...其背后的环境变量环境变量作用E2E_HEADLESSfalse显示浏览器并将每一步放慢到 50msSlowMoE2E_KEEP1运行结束后保留容器仅在套件自行拉堆栈时有意义E2E_DEBUG1记录每个状态码 ≥ 400 的 HTTP 响应E2E_BROWSERSchromium收窄渲染测试使用的浏览器引擎是缩短本地运行最快的方式限流rate-limit响应无论是否设置E2E_DEBUG都会被记录因为它们若不显式暴露最终只会表现为莫名的定位器超时。这在 e2e/e2e_test.go 的newPageInContext中实现状态码 429 的响应会被记录为页面问题rate limited并打印[WARN]日志。覆盖率后端与 Widget 的双端采集make e2e-cover对应目标调用 e2e/coverage.sh。套件要回答的问题是“浏览器测试到底覆盖了后端和 Widget 的哪些代码”而这两端对常规覆盖率工具都不可见后端运行在容器里而非测试进程内go test -cover看不到Widget 运行在浏览器里jest 只能报告其自身套件触及的代码。因此两端都在构建时插桩。后端半区go build -covercompose-e2e-coverage.yml 以 overlay 方式叠加在基础堆栈之上通过一个COVERAGE构建参数同时插桩两端。注意它只给第一个服务remark42传构建参数所有实例运行的是第一个服务构建出的同一镜像插桩一个即插桩全部。同时它为每个 remark42 实例挂载GOCOVERDIR/coverage目录并映射到宿主机的e2e/coverage/实例名。在 Dockerfile 中COVERAGE1触发go build -cover -covermodeatomic -coverpkg./... -o remark42 -ldflags -X main.revision${version} ./app插桩二进制以atomic模式在实例退出时把 profile 写入GOCOVERDIR。运行结束后e2e/coverage.sh 用go tool covdata textfmt将各实例的 profile 目录合并为e2e/coverage/e2e.cov并过滤_mock.go与单元测试相同的排除规则最后在backend/下执行go tool cover -func打印总计。前端半区babel-plugin-istanbulWidget 使用babel-plugin-istanbul依赖声明见 frontend/apps/remark42/package.json插桩计数器随 bundle 运行在页面上。套件在每个文档即将被替换时以及清理阶段从所有 frame 中读出计数器写入e2e/coverage/frontend最后由nyc合并该目录并生成报告。前端插桩的开关由 frontend/apps/remark42/.babelrc.js 中的E2E_COVERAGE 1控制。为什么 overlay 是独立文件overlay 独立成文件是因为短格式short form的 bind mount 在宿主机路径缺失时会自动创建它。若把挂载写进基础文件 compose-e2e-test.yml普通的make e2e就会自己创建e2e/coverage目录其属主是 Docker 守护进程的运行用户。普通运行必须不留下任何覆盖率痕迹而compose-e2e-test.yml正是普通运行所使用的文件。覆盖率运行中的失败保护有三种“报告为空却看起来正常”的情况套件对每一种都改为显式失败被杀死的实例写不出 profile实例被要求以 30 秒宽限期停止随后逐个检查每个目录而非只看总量——因为六个干净退出加一个被 kill 的实例会合并成一份看似合理、实则把该实例代码读成“未触及”的报告。失败信息会点名没有产出 profile 的服务e2e/coverage.sh 的missing检查。失败的套件仍然有值得保留的覆盖率运行退出状态被保留但实例无论如何都会被停止、profile 照常合并——最需要解释的那次运行绝不能丢弃自己的证据。coverage.sh用status变量累计套件与nyc的退出码并最终exit $status。普通堆栈应答了插桩堆栈E2E_COVERAGE同时喂给 e2e/stamp.sh 和镜像构建两个堆栈因此携带不同 stamp套件会拒绝不是为它构建的堆栈。只有值1才插桩stamp 和 Dockerfile 都是这个判据所以E2E_COVERAGE0就是普通构建而不是第三种变体。与单元测试合并后端 profile 使用atomic模式、且应用与单元运行相同的_mock.go排除规则因此两端属于同一总体可以合并为一个数字。只需追加无需重复mode:头cat profile.cov combined.cov tail -n 2 e2e/coverage/e2e.cov combined.cov cd backend go tool cover -func../combined.cov读取必须在backend/目录下进行covdata以完整导入路径写入文件名go tool cover通过go list解析它们从仓库根目录没有go.mod运行会报“没有模块提供该包”而非任何覆盖率信息。atomic也是-race唯一接受的模式因此插桩构建在未来若启用-race仍保持兼容。Widget 半区的三个正确性要点Widget 覆盖率采集有三个“错了会静默咬人”的点页面与其 iframe 都携带计数器embed 脚本运行在测试导航到的页面Widget 运行在下方 frame测试还可能打开更多 frame因此每个 frame 都会被询问而某个 frame 没有 bundle 不算错误。计数器属于 document替换 document 就会丢弃它们在每次导航、每次 reload 以及 Widget 自身的destroy之前都要快照清理时也要快照。否则“先操作再刷新”的测试只会报告最后一份 document 运行了什么总量看似合理却丢了测试存在的意义。仅在结束时读取曾损失 6 个点的覆盖。路径是 bundle 构建时的路径镜像在/srv/frontend/apps/remark42下构建宿主机上解析不到因此在读取计数器时剥离前缀报告从剩余路径所相对的包运行。唯一不可选的配置是 frontend/apps/remark42/.babelrc.js 中的coverageGlobalScopeFunc: false。默认的 preamble 通过new Function访问全局对象而 Widget 文档以script-src self unsafe-inline服务浏览器会直接拒绝bundle 在渲染任何东西之前就抛出异常——Widget 根本不会出现。该文件还同时说明了coverageGlobalScope: window的配置。插桩是两个半区的构建参数绝不会进入发布镜像。当测试失败时失败的测试会把 Playwright trace 写入e2e/traces/CI 将其作为 artifact 上传。没有其他东西会写 trace所以带 artifact 的运行就是有失败需要查看的运行。用npx playwright show-trace e2e/traces/name.zip打开。CI不会重试失败测试套件还太年轻一次失败本身就是关于套件自身的证据重试反而会掩盖间歇性回归。E2E_RUN_ID把运行使用的线程 URL 打上 CI 运行 id因此 trace 中的线程 URL 能指出它来自哪次运行。它不跨运行携带数据堆栈是一次性的本地用同一 id 运行只会得到空数据库上的相同 URL。进一步的排查手段docker compose -f compose-e2e-test.yml logs # 服务端日志 # mailpit 的 Web UIhttp://127.0.0.1:8025邮件相关失败测试还会记录浏览器写入 console 的内容——失败的请求或 Widget 端错误都会出现在那里但它们只是上下文。真正会单独导致测试失败的是页面中的未捕获异常和限流响应——这两者都会静默腐蚀一次运行渲染时抛异常的 Widget 仍能满足大多数断言而被拒绝的/auth/status会渲染成“未登录的读者”。套件运行所依赖的测试堆栈堆栈印章stamp拒绝“不是本检出的堆栈”套件拒绝一个正在运行但不是从被测源码拉起的堆栈。每个检出都会构建 Compose 文件指定的同一镜像标签ghcr.io/umputun/remark42:dev因此来自其他 worktree、或本 worktree 编辑前的堆栈会在相同端口应答并通过所有就绪探针却提供着没人看的代码。e2e/stamp.sh 对backend、frontend、Dockerfile、docker-init.sh和e2e/telegramstubCompose 从本仓库源码构建的第二张镜像的内容做摘要Compose 把它放进容器环境变量E2E_SOURCE_STAMP套件读回并比对e2e/harness_test.go 的sourceStamp/stackStamp/assertStackMatches。摘要基于内容而非HEAD所以只动测试套件的提交不会让已有堆栈失效。make e2e-up以同样方式打 stamp手工拉起的堆栈也会被接受。不匹配时失败信息会提示make e2e-down。推送前还应运行CI 都会执行且因构建标签不属于普通go vet ./...cd e2e go vet -tagse2e ./... golangci-lint run --build-tagse2e --config ../backend/.golangci.yml十二个服务逐一说明仓库根目录的 compose-e2e-test.yml 运行十二个服务每个端口都绑定回环接口——堆栈持有已知密钥与管理员共享 idgo test可在无人值守时启动它因此绝不能对网络可达remark42:8080主实例带:8084的 dev OAuth2 provider启用匿名与邮箱登录remark42-shortedit:8081EDIT_TIME15s、仅匿名登录——dev OAuth2 provider 端口固定为 8084、无法发布两次因此后续实例都只开匿名。它的存在使“过期编辑”路径无需为默认五分钟窗口而挂起测试remark42-adminedit:8082ADMIN_EDITtrue加同样的短窗口覆盖管理员应享有的无限编辑窗口曾由 #1986 报告前端忽略该设置。启用邮箱认证ADMIN_SHARED_ID设为admineditexample.com的 SHA-1 派生 IDemail_0212c0d9...因为邮箱 ID 只由地址决定可提前写死而匿名 ID 还掺入客户端地址在笔记本和 CI 上不一致remark42-jwtheader:8083AUTH_SEND_JWT_HEADERtruetoken 走 header 而非 cookie前端必须自己保管曾由 #1877 报告每次刷新丢失remark42-noauth:8085完全没有认证 provider曾被 #1456 报告渲染成无话可说的 Widget并把ALLOWED_HOSTS设为自身地址兼作“拒绝被嵌入他处”的反向用例remark42-anonvote:8086ANON_VOTE与其依赖的VOTES_IP——默认配置会拒绝匿名投票见 backend/app/rest/api/rest_private.go 的投票处理host-site:8090nginx 提供 e2e/hostsite/ 页面——一个 Widget 并非来自其域名的页面覆盖手册中描述的独立域名separate-domain部署其他所有宿主页面都由 remark42 自己服务。e2e/hostsite/post.html 嵌入主实例restricted.html嵌入只允许自身域名的实例remark42-https:8443TLS 下的 WidgetAUTH_SAME_SITEnoneAUTH_SEND_JWT_HEADERtrue。header 模式让 Widget 通过setAuthCookie自行写 Cookie其选择的属性因此可被观测匿名与邮箱登录都启用——Widget 的写手逻辑以X-JWTheader 为准而非 provider这个假设值得测量而非断言host-site-https:8444TLS 下提供同一批 e2e/hostsite/ 页面的 nginx使嵌入既跨站又安全post-https.html是其页面remark42-telegram:8087通过TELEGRAM_API_URL指向下方 stub 的 Telegram 认证。它单独成实例因为 Telegram 是认证 provider加入主实例会改变其他用例从认证面板读出的 provider 列表telegram-stub:8091以 Telegram bot API 应答认证流程用到的四次调用通过/control/send接收注入的 update通过/control/sent暴露 bot 的回复——这两个端点代表浏览器无法执行的、发生在 Telegram 内部的交换。源码在 e2e/telegramstub是模块中唯一没有e2e构建标签的文件Compose 从一次性模块把它构建成独立镜像测试的浏览器工具链不进此镜像mailpit:8025截获邮箱认证验证消息与订阅 token供套件读回见 e2e/e2e_test.go 的mailpitMessage。两个 TLS 服务从e2e/tls/读取自签名证书由 e2e/tls/generate.sh 生成且被.gitignore排除。make e2e-up、CI workflow 与ensureStack都会在 Compose 之前运行它——所以裸docker compose up手工拉堆栈是唯一需要先手动生成证书的路径。每个浏览器上下文和就绪客户端都接受该证书且只与它通信。主实例启用通知模块NOTIFY_USERSemail没有它配置里email_notifications为 falseWidget 永不渲染订阅控件整个订阅-确认-退订流程从浏览器不可达。第一个之后的其余 remark42 实例与remark42-telegram都只开匿名登录理由同remark42-shorteditdev OAuth2 provider 绑定固定端口 8084无法发布两次。为测试而设、不为真实场景而设的四个设置REMARK_URL用主机名而非127.0.0.1dev OAuth2 服务器绑定它从REMARK_URL读出的主机go-pkgz/auth 的localBindAddr容器内的回环绑定无法发布。浏览器用--host-resolver-rules把名字映射回本地见 e2e/e2e_test.go 的 Chromium 启动参数UPDATE_LIMIT100默认每秒 0.5 次的更新限流会拒绝任何连续发两条的测试。对应的速率限制器配置在 backend/app/rest/api/rest.go/auth/路由组固定为rateLimiter(2)每秒两次、突发等于速率——README 称其为 backend/app/rest/api/rest.go 第 242 行附近的裸字面量而非设置项每个浏览器上下文有自己的转发客户端 IP新上下文使用限流器的初始配额后续认证动作通过pauseForAuthLimit等待一个令牌补充间隔e2e/e2e_test.go 中固定 600msTRUSTED_PROXY保持未设置堆栈仅回环可达harness 验证其每上下文的X-Real-IP能到达后端并分离认证限流桶e2e/harness_test.go 的TestHarness_ForwardedIPSeparatesAuthLimiter与TestHarness_BrowserContextsHaveIndependentAuthLimiters。VOTES_IP遵循同样的读者模型一个浏览器上下文就是一个投票者 IP。需要同一读者重复操作的投票去重用例必须在同一上下文内完成。套件无法覆盖的范围协议相关的可达性与三个引擎的限制堆栈在两个服务上携带 TLS因此浏览器按页面协议把关的行为都可达SecureCookie、SameSiteNone、Partitioned以及任何依赖window.location.protocol的逻辑——这些用例都在 e2e/https_test.go。但对这些用例仍无法使用 Chromium 之外的引擎主机名所需的 resolver 规则是 Chromium 专属 flag。Telegram 夹具的边界Telegram 夹具同时覆盖认证与订阅。stub 只实现getMe、getUpdates、sendMessage与getUserProfilePhotos见 e2e/telegramstub/main.go 的route分派因此它不用公共 bot API 的语义来约束 Widget读者向 Telegram 客户端的交接由测试进程注入。套件同时驱动TELEGRAM_API_URL的两个消费方认证通过 bot 签名读者通知则通过同一轮询确认、持久化、移除并重复订阅。第三方 Cookie 分区的陷阱与“控制哨兵”Playwright 自带的默认--disable-features参数携带ThirdPartyStoragePartitioning它压过经Args传入的--test-third-party-cookie-phaseout与--block-third-party-cookies。这样配置的运行会像没有任何 flag 一样保留普通第三方 Cookie——看似证明了什么实则什么都没证明。杠杆是启动选项里的IgnoreDefaultArgs丢掉该默认条目重新提供去掉该特性的--disable-features列表——这正是 e2e/https_test.go 的TestHTTPS_SessionSurvivesThirdPartyCookieBlocking所做的。在跨站 https 嵌入上测得普通第三方 CookiePartitionedCookiePlaywright 默认保留保留启用分区去掉该特性丢弃存储带分区键因此一次“阻断”运行必须先断言一个控制哨兵其报告才可信在 Widget frame 内设置一个普通SameSiteNoneCookie并要求浏览器丢弃它。若它存活说明本次运行根本没在阻断任何东西。参数列表是 Playwright 自有的、随版本变化的这个控制正是防止它在版本升级后悄悄失效的机制。该控制必须通过同一个 frame evaluate 中的document.cookie读写绝不要用page.Context().Cookies()。两者是不同通道、之间没有顺序保证Playwright 1.62.1 附带的 Chromium 里Blink 的CookieJar::SetCookie排队写入后直接返回渲染进程自己的document.cookiegetter 才是强制写入落地的屏障而 Playwright 的上下文读取是浏览器会话级Storage.getCookies根本不碰该 frame 的 jar。这样读出的控制可能因写入未落地而找不到名字——那正是该控制存在要排除的结果。它还写入一个合法Secure; SameSiteNone; Partitioned哨兵并要求其存在使“浏览器拒绝控制”与“什么都没写入”可区分。这些都够不到 Widget 自身的存储回退方案——认证面板在IS_THIRD_PARTY !IS_STORAGE_AVAILABLE时提供comments.html。IS_STORAGE_AVAILABLE即使分区被正确强制执行也保持为 true因为 Chromium 是分区localStorage而非拒绝它该常量背后的探测永不抛异常、条件无法触发。那个用例需要 WebKit而不是 Chromium flag。另注意Partitioned Cookie 并不能让跨域 OAuth 工作。分区键是设置 Cookie 那一刻的顶层站点而oauthSignin打开 popup——popup 自身是顶层上下文回调 Cookie 键到认证主机frame 键到嵌入方两者永不匹配。真正能嵌入工作的形式是 Cookie 写在 frame 内——匿名、邮箱与 Telegram。断言 OAuth 能跨域工作就是在断言一件不真实的事。隔离机制每个测试从演示页的查询字符串获得自己的评论线程演示页把window.location.href作为remark_config.url传入而 remark42 以 URL 为评论键e2e/hostsite/post.html 中也是整条地址。每次运行独有的 idrunIDE2E_RUN_ID可固定见 e2e/e2e_test.go把本线程与早期运行遗留的线程分开。线程 URL故意保留测试名携带的下划线折叠持久化以页面 URL 为键含下划线的 URL 正是值得覆盖的用例。浏览器选择e2e/iframe_test.go 组在 Chromium、Firefox 与 WebKit 三种引擎下运行。它关乎渲染而非逻辑Widget 保持 frame 隐藏直到其文档报告自身已初始化而守护这一点的“不透明画布”是 WebKit 行为仅 Chromium 无法覆盖它。engines()函数e2e/e2e_test.go默认返回三种引擎可用E2E_BROWSERS收窄引擎按需安装并缓存复用browserFor。这些测试以127.0.0.1直接寻址服务器而非名字因为--host-resolver-rules是 Chromium flag而它们不需要 dev OAuth2——那是主机名存在的唯一理由。其余一切只在 Chromium 中运行理由恰好相反那些测试要登录登录需要 dev OAuth2 provider从宿主机按名访问它只有 Chromium 能做到。在其他引擎中运行它们等于把套件放回 Compose 网络内部。选择器测试如何抓住生产 bundle生产 bundle 会剥离data-testid见 frontend/apps/remark42/.babelrc.js 引用的removeTestId插件所以测试使用线上真实存在的抓手Widget 保留在 CSS Modules 之外的稳定 class 钩子.auth-button、.auth-submit、.comment-actions、.comment-actions-additional、.sort-picker、.preloader、.comments-counter、纯图标控件上的title属性以及可见文本。以下形态值得记住.auth只在登出时存在等待它会在登录后挂起widget()等待评论表单两种状态都在生产构建把每个 CSS Modules 类名哈希成短不透明 id测试无法持有组件自身类role可以页脚是[rolecontentinfo]编辑倒计时是[roletimer]评论通过IntersectionObserver渲染折叠线以下的评论是没有文本的空article。任何写成文本过滤器的“不存在”断言都会在评论已删除和评论仅在屏幕外之间误判通过数article的数量articleCount才是正确做法折叠线程会隐藏评论文本按文本过滤的定位器会停止匹配被测元素。TestThread_CollapsePersistsAcrossReload改锚定评论 idtextFoo匹配大小写不敏感的子串评论自身文本含该短语就会满足本为页面副本准备的定位器两个匹配即是严格模式失败textFoo精确匹配。这常在后期暴露折叠线以下的评论在 IntersectionObserver 下为空碰撞可能在本地通过、在 CI 失败?是page.Route所取 glob 的单字符通配符带查询字符串书写的模式永远匹配不到它命名的请求路由不会被拦截用例会对未修改的响应通过。带查询字符串一律用正则如TestProfile_LoadingAndFailureStates所做。总结remark42 的 e2e 套件把“浏览器里真实发生的”作为最终裁判十二个服务的 Compose 堆栈覆盖了编辑时限、JWT header、无认证、匿名投票、跨域嵌入、TLS 与 Telegram 等每一种无法在单一实例上验证的部署模式构建时插桩让浏览器测试能报告后端与 Widget 两端的真实覆盖源码摘要印章保证了堆栈永远来自被测代码而失败时保留的 Playwright trace、永不重试的 CI 策略、以及覆盖为空即失败的保护让每一次失败都成为可解释的证据。对任何想深入 remark42 开发、或想为自己的 Web 组件搭建同类浏览器级验证体系的人来说这套工程都是可以直接参考与复用的范本。赞分享后端前端【免费下载链接】remark42comment engine项目地址https://gitcode.com/gh_mirrors/re/remark42点击查看免费下载相关推荐authentik 前端浏览器端到端测试指南基于 Playwright Vitest 的 UI 驱动测试规范与 Fixture 体系authentik 前端浏览器端到端测试指南基于 Playwright Vitest 的 UI 驱动测试规范与 Fixture 体系 authentik后端认证鉴权单点登录IronClaw E2E 测试套件实战基于 Playwright 与 Reborn serve 的浏览器级端到端测试指南IronClaw E2E 测试套件实战基于 Playwright 与 Reborn serve 的浏览器级端到端测试指南 output_article Ir人工智能AI 应用交互助手AI AgentIronClaw E2E 测试体系基于 Playwright Mock LLM Emulate 的浏览器级端到端测试实战IronClaw E2E 测试体系基于 Playwright Mock LLM Emulate 的浏览器级端到端测试实战 IronClaw 的端到端测人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考