前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载本文以仓库内 .agent/skills/webapp-testing/SKILL.md 为骨架结合 DillingerNext.js 14 在线 Markdown 编辑器仓库中的真实 E2E 测试、Playwright 配置与 API 路由测试展开。读完本文你将掌握一套可落地的 Web 应用测试方法论从深度审计清单、E2E 优先级排序、Playwright 配置调优到 API 边界测试、测试组织与 CI 集成并能在 Dillinger 仓库中找到每一处对应的实现证据直接对照。1. 测试工具箱运行时脚本与依赖准备SKILL 文档为自动化浏览器测试提供了一组开箱即用的运行时脚本核心入口是scripts/playwright_runner.py脚本用途用法scripts/playwright_runner.py基础浏览器测试python scripts/playwright_runner.py https://example.com同上带截图截图辅助python scripts/playwright_runner.py url --screenshot同上无障碍检查可访问性审计python scripts/playwright_runner.py url --a11y脚本依赖 Python 侧安装 Playwright 及 Chromiumpip install playwright playwright install chromium需要说明的是这一通用脚本属于技能文档中的通用运行器方案Dillinger 仓库实际的 E2E 运行体系是playwright/test驱动。在 package.json 中可以找到完整命令链test: npm run test:unit npm run test:e2e, test:unit: vitest run, test:e2e: npm run build playwright test, test:e2e:headed: npm run build playwright test --headed, verify: npm run lint npm run typecheck npm run test:unit npm run test:e2e其中test:e2e先执行npm run build再跑 Playwrightverify则把 lint、类型检查、单元测试与 E2E 全链路串起来与 SKILL 文档中CI 流水线先装依赖、再装浏览器、再跑测试的思想一致。开发依赖中的playwright/test^1.58.2即仓库 E2E 的实际载体。2. 深度审计方法先发现后系统化测试SKILL 文档强调 Web 应用测试的第一原则是发现并测试一切不留任何未测试路由。审计的第一步是发现Discovery目标如何发现路由Routes扫描app/、pages/、router 文件API 端点Grep 搜索 HTTP 方法GET/POST/PUT/DELETE组件Components定位组件目录功能Features阅读文档在 Dillinger 仓库中这套发现路径可以精确落地路由Next.js App Router 结构集中在 app 目录包括编辑器主页 app/page.tsx、导出、导入、OAuth 回调等 API 路由如 app/api/export/html/route.ts组件位于 components 下的editor/、preview/、sidebar/、modals/、navbar/等目录API 端点app/api/下按github/、dropbox/、google-drive/、onedrive/、bitbucket/等云服务组织的 route.ts 文件对应各云存储集成功能docs 目录下的设计文档与迁移计划。发现之后进入系统化测试三步法Map映射——列出所有路由与 APIScan扫描——验证它们都能正常响应Test测试——覆盖关键路径。Dillinger 仓库的测试布局正是这三步的产物tests/routes/覆盖 API 路由tests/e2e/覆盖关键用户路径tests/components/、tests/hooks/、tests/lib/、tests/store/覆盖单元层面。3. Web 测试金字塔SKILL 文档用金字塔模型说明 Web 应用的测试投入比例/\ E2E (少量) / \ 关键用户流程 /----\ / \ Integration (适量) /--------\ API、数据流 / \ /------------\ Component (大量) 单个 UI 部件要点E2E 测试昂贵只应用于关键路径大量测试应落在金字塔底部的组件与单元层。Dillinger 仓库的 tests 目录正是这一模型的实证e2e/仅 5 个 spec 文件smoke、editor、import-export、logobar、settings-sidebar而组件、hooks、lib、store 的单元测试文件更多更细金字塔底部明显更厚。4. E2E 测试原则4.1 测什么按优先级排序优先级测试内容1快乐路径Happy path用户流程2认证流程Authentication flows3关键业务操作Critical business actions4错误处理Error handling在 Dillinger 的 tests/e2e/smoke.spec.ts 中可以看到典型的快乐路径覆盖加载编辑器外壳 → 断言标题、侧边栏切换按钮、#preview预览区、字数与字符数统计 → 隐藏/显示预览 → 打开设置弹窗 → 验证 Night Mode 开关可见。这正是先测外壳稳定再深入细节的冒烟策略。4.2 E2E 最佳实践实践原因使用>// 摘自 tests/e2e/settings-sidebar.spec.ts确定性状态种子注入 function seedLocalStorage( documents seededDocuments, current seededDocuments[0], profile defaultProfile ) { return (args) { if (window.localStorage.getItem(files)) return; window.localStorage.setItem(files, JSON.stringify(args.documents)); window.localStorage.setItem(currentDocument, JSON.stringify(args.current)); window.localStorage.setItem(profileV3, JSON.stringify(args.profile)); }; }这一模式是清理状态、测试独立的实战范本不依赖外部数据库或网络用种子数据把每个用例固定在同一初始状态从根上消除顺序依赖导致的 flaky。5. Playwright 原理与配置实践5.1 核心概念概念用途Page Object Model封装页面逻辑提升复用与可读性Fixtures可复用的测试前置设置Assertions内置自动等待auto-waitTrace Viewer调试失败用例回放操作轨迹5.2 配置推荐配置项推荐值RetriesCI 上设为 2Traceon-first-retryScreenshotson-failureVideoretain-on-failureDillinger 仓库的 playwright.config.ts 与推荐值几乎逐条对应可作标准配置模板export default defineConfig({ testDir: ./tests/e2e, fullyParallel: true, reporter: list, timeout: 45_000, expect: { timeout: 5_000 }, use: { baseURL, trace: on-first-retry, screenshot: only-on-failure, video: retain-on-failure, }, projects: [{ name: chromium, use: { ...devices[Desktop Chrome] } }], webServer: { command: npx next dev -H 127.0.0.1 -p ${port}, url: baseURL, reuseExistingServer: !process.env.CI, timeout: 180_000, }, });要点解读trace: on-first-retry仅在重试时录制 trace兼顾调试能力与性能开销对应推荐值video: retain-on-failure只在失败时保留视频是 CI 排障的关键证据fullyParallel: true文件级并行对应 SKILL 文档中Per file 是 Playwright 默认并行策略webServer自动启动next dev监听127.0.0.1:3005并等待就绪reuseExistingServer: !process.env.CI在本地复用已启动的 dev server、在 CI 中强制全新启动——配置注释还记录了关键经验使用 dev 模式因为 production build 存在预先存在的预渲染错误timeout: 45_000/expect.timeout: 5_000为慢速断言如异步 Markdown 渲染预留充足等待对应避免硬编码等待、使用自动等待的原则。事实上 tests/e2e/editor.spec.ts 中针对异步预览渲染的断言特意放宽到{ timeout: 10_000 }。6. 视觉测试6.1 何时使用场景价值设计系统Design system高营销页面Marketing pages高组件库Component library中动态内容Dynamic content较低6.2 策略Baseline screenshots基线截图Compare on changes变更时对比Review visual diffs人工审阅视觉差异Update intentional changes确认有意变更后更新基线7. API 测试原则7.1 覆盖维度维度测试点状态码200、400、404、500响应结构匹配 schema错误消息用户友好边界情况空值、大体积、特殊字符7.2 Dillinger 中的 API 测试实证仓库在 tests/routes 下用 Vitestvitest-environment node直接调用 Next.js 路由处理函数做纯 Node 环境测试tests/routes/export-html.route.test.ts 是教科书式示例it(rejects missing markdown, async () { const response await exportHtml( new Request(http://localhost/api/export/html, { method: POST, body: JSON.stringify({}), }) as never ); expect(response.status).toBe(400); }); it(renders styled and plain HTML variants with stable filenames, async () { // styled: true → 响应体包含 style // styled: false → 响应体不含 style expect(styledResponse.headers.get(Content-Disposition)).toContain( filenameExported.html ); expect(await styledResponse.text()).toContain(style); expect(await plainResponse.text()).not.toContain(style); });该测试完整覆盖了状态码缺参返回 400、响应结构HTML 是否含style样式块、响应头Content-Disposition文件名稳定性三类维度与 SKILL 文档中状态码 响应结构 错误消息 边界情况的 API 测试原则一一对应。同类测试还包括export-markdown、export-pdf、github.route、import-html-to-markdown、upload-image等路由。8. 测试组织结构与命名约定8.1 文件结构SKILL 文档推荐的标准结构tests/ ├── e2e/ # 完整用户流程 ├── integration/ # API、数据 ├── component/ # UI 单元 └── fixtures/ # 共享数据Dillinger 仓库的 tests 目录与之同构integration 层以routes/目录呈现tests/ ├── e2e/ # 完整用户流程Playwright ├── routes/ # API 路由测试Vitest ├── components/ # UI 单元测试 ├── hooks/ # 自定义 hooks 测试 ├── lib/ # 核心库测试markdown、export、import 等 └── store/ # Zustand 状态管理测试这种E2E 只测关键路径、API 与单元测试铺底的布局正是金字塔模型的落地形态。8.2 命名约定模式示例基于功能Feature-basedlogin.spec.ts描述性Descriptiveuser-can-checkout.spec.tsDillinger 的 E2E 文件命名两者兼取smoke.spec.ts功能型、settings-sidebar.spec.ts功能型、import-export.spec.ts功能型而测试用例名则全部采用描述性句式如switches between documents and updates the editor and preview、deletes a document after confirmation、hides word count when disabled in settings见 tests/e2e/editor.spec.ts失败时可读性极佳。9. CI 集成9.1 流水线步骤安装依赖Install dependencies安装浏览器Install browsers运行测试Run tests上传产物Upload artifactstraces、screenshots9.2 并行化策略策略适用场景按文件并行Per filePlaywright 默认策略分片Sharding大型测试套件多 Worker多浏览器并行Dillinger 的 playwright.config.ts 通过fullyParallel: true启用文件级并行package.json的verify脚本把 lint → typecheck → 单元测试 → E2E 串成一条可放入 CI 的完整流水线。结合配置中的trace/screenshot/video三件套CI 失败时能自动保留 trace、截图与视频作为可下载的诊断产物与文档推荐的流水线第 4 步上传 artifacts完全吻合。10. 反模式清单❌ 不要✅ 要测试实现细节Test implementation测试行为Test behavior硬编码等待Hardcode waits使用自动等待Use auto-wait跳过清理Skip cleanup隔离测试Isolate tests忽视 flaky 测试Ignore flaky tests修复根因Fix root cause在 Dillinger 仓库中可以找到每条反模式的正面对照测行为而非实现smoke.spec.ts用getByRole断言Toggle sidebarHide previewOpen settings等用户可见交互从不触碰组件内部状态自动等待替代硬编码所有断言依赖 Playwright 内置 auto-wait异步渲染场景通过显式timeout参数而非page.waitForTimeout处理清理与隔离addInitScript种子注入 仅空 localStorage 才注入的守卫保证用例间互不污染修复根因playwright.config.ts注释记录了对 dev/prod 模式差异的真实根因排查结论而非简单绕开问题。结语Remember: E2E tests are expensive. Use them for critical paths only.Dillinger 仓库把 SKILL 文档中的每一条原则都落成了可运行、可复现的代码fullyParallel的并行配置、on-first-retry的 trace、addInitScript的确定性状态种子、getByRole的行为级断言以及 Vitest 直调路由函数的 API 测试。无论你是要给 Dillinger 增加新的 E2E 用例参考 tests/e2e 现有 spec 的模式还是为下一个 Web 应用搭建测试体系以 playwright.config.ts 为起点这套深度审计 → 金字塔分层 → 关键路径 E2E → 边界化 API 测试 → CI 产物留证的流程都值得直接照搬。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐AG Kit 实战Web 应用测试E2E Playwright与深度审计方法论AG Kit 实战Web 应用测试E2E Playwright与深度审计方法论 本文基于 AG Kit 仓库中的 webapp testing 技能文人工智能AI 技能dotnet-podcasts 测试策略Playwright E2E 测试实战指南dotnet podcasts 测试策略Playwright E2E 测试实战指南 在当今快速迭代的软件开发环境中确保应用质量至关重要。dotnet pod示例工程后端移动开发微服务cal.com测试策略Playwright E2E测试完整指南cal.com测试策略Playwright E2E测试完整指南 作为开源日历应用的领军者cal.com采用Playwright实现端到端E2E测试确保后端前端企业应用上一篇告别投稿焦虑Elsevier投稿追踪工具让你实时掌握审稿进度下一篇终极Godot资源解包指南3分钟掌握.pck文件提取技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考