e2e

Solid

执行 E2E 测试用例。 根据测试用例的验证类型(ui/api/database)选择正确的工具执行验证。

Testing & QA 2,168 stars 213 forks Updated today NOASSERTION

Install

View on GitHub

Quality Score: 86/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# E2E 测试执行指南 执行 `e2e/` 目录下的端到端测试用例。 ## 🚨 强制要求:UI 测试必须执行 **⚠️ 禁止跳过 UI 测试!UI 测试是 E2E 测试的核心,必须使用 MCP Chrome DevTools 执行真实的浏览器验证。** ### UI 测试执行规则 1. **不可跳过**:任何 `verification.type: ui` 的测试步骤都必须执行 2. **不可替代**:禁止用 API 调用代替 UI 验证 3. **必须使用浏览器**:使用 MCP Chrome DevTools 工具(`mcp__chrome-devtools__*`) 4. **验证真实渲染**:确保页面元素真实渲染,而非仅验证数据存在 ### 为什么 UI 测试重要? - API 测试只验证数据,UI 测试验证用户体验 - 前端渲染问题只能通过 UI 测试发现 - 交互逻辑(点击、输入、导航)必须在浏览器中验证 - 响应式布局和样式问题需要实际渲染才能发现 ## ⚠️ 关键:使用当前 Worktree 的开发环境 **每个 worktree 有独立的 Docker 环境和端口配置!** ### 1. 定位当前 Worktree 的 dev 环境 ```bash # 当前工作目录的 deploy/dev 目录 cd <当前worktree根目录>/deploy/dev # 例如: # /Users/stone/Works/AIO/AgentsMesh-Worktrees/feature-payment-membership/deploy/dev # /Users/stone/Works/AIO/AgentsMesh-Worktrees/feature-xxx/deploy/dev ``` ### 2. 获取当前环境的端口配置 **必须先 source 当前 worktree 的 .env 文件获取正确端口:** ```bash cd <当前worktree>/deploy/dev source .env # 查看关键端口 echo "WEB_PORT: ${WEB_PORT}" # Web/Nginx 端口(用于浏览器和 API) echo "POSTGRES_PORT: ${POSTGRES_PORT}" # 数据库端口 echo "REDIS_PORT: ${REDIS_PORT}" # Redis 端口 ``` ### 3. Docker 容器命名规则 容器名称包含 worktree 目录名,格式为:`agentsmesh-<worktree-dir>-<service>-1` ```bash # 查看当前环境的容器 docker compose ps # 示例容器名: # agentsmesh-feature-payment-membership-postgres-1 # agentsmesh-feature-payment-membership-backend-1 # agentsmesh-feature-payment-membership-web-1 ``` ### 4. 确认环境运行中 ```bash cd <当前worktree>/deploy/dev docker compose ps # 确认所有服务 Up 且 healthy ``` --- ## 环境变量与 URL 构建 ### 浏览器 URL(UI 测试) ```bash # ...

Details

Author
AgentsMesh
Repository
AgentsMesh/AgentsMesh
Created
3 months ago
Last Updated
today
Language
Go
License
NOASSERTION

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

qa-ui

実装完了後の UI を検証したいとき、または「UI を確認して」「QA して」「画面の動作確認」と頼まれたときに使用。ChromeDevTools MCP を使い、独立コンテキストの QA エージェントが画面を操作して AC 単位で pass/fail を判定する。

1 Updated yesterday
YasuakiOmokawa
Testing & QA Listed

testing

Testing strategies and methodologies including TDD and E2E testing. Use when writing tests, implementing TDD workflow, or setting up E2E test infrastructure.

42 Updated 1 months ago
xiaobei930
Testing & QA Solid

qae2e-playwright

Playwright E2E 测试完整方法论,涵盖项目初始化、Page Object Model、认证复用、API Mock、视觉回归、多浏览器测试、CI 集成和调试技巧

410 Updated 2 days ago
echoVic
Testing & QA Listed

e2e-http-verify

用 cdt-cli HTTP server + vite proxy + 浏览器 `?http=1` 入口跑端到端真数据验证**用户可感知 + HTTP transport 暴露**路径的修法。**只要**用户说"用 cli 起 server / 用 http 接口验证 / 浏览器自动化测试 / 真数据 e2e / chrome devtools 端到端 / 验证修法 / 用户感知 bug 复现 / 桌面端看不到修复 / sidebar 显示异常 / 切 group 慢 / 列表渲染 / 卡顿"或显式 `/e2e-http-verify`,**都用这个 skill**。**agent 在以下时机也宜自动调用**(无需用户念关键词):(a) 改完 HTTP route / SSE 路径 / list_sessions / sidebar 渲染 / IPC 字段被前端消费的路径准备宣告完成前;(b) 用户报"我重启了桌面端还是没修好" / "看不见修复" / "刷新没用"。**不适用**(避免 over-trigger):纯 Tauri 专属 API(通知 / 托盘 / setBadgeCount)/ 纯 backend 内部重构 / 没有用户可见路径的纯算法改动 / 纯样式微调 / bump version / docs。避免每次重新摸 vite proxy / SSE prelude / BrowserTransport 路由 / 端口冲突 / chrome-devtools mcp evaluate_script 陷阱,也避免修完只跑 unit test + mockIPC 就声称完成(mockIPC fixture ≠ 真后端数据,桌面端 binary 不一定用上新代码)。

1 Updated today
snowzhaozhj
Testing & QA Listed

doa-e2etest

端到端测试全流程:安装配置 Playwright → 编写 E2E 测试用例 → 执行测试 → 生成精美 HTML 报告 → 输出 PDF。USE FOR: E2E测试、端到端测试、Playwright测试、前端自动化测试、编写E2E用例、生成测试报告、测试报告PDF、测试报告HTML、Playwright配置、自动化回归测试、UI测试、冒烟测试。DO NOT USE FOR: 单元测试(使用 test-driven-development skill)、API测试、性能测试。

4 Updated yesterday
medalsoftchina