Whiteboard 测试体系完全解析Vitest 浏览器模式、Chromium DOM 测试与 E2E 旅程清单【免费下载链接】whiteboardopen-source canvas for thoughtful software design项目地址: https://gitcode.com/gh_mirrors/whiteboard36/whiteboardWhiteboard 是一款开源软件设计画布open-source canvas for thoughtful software design它把设计文档、流程图与代码评审整合在桌面应用中。本文带你完整拆解 Whiteboard 的测试体系Vitest 浏览器模式如何驱动 Chromium 做真实 DOM 测试、集成测试如何把关运行时依赖、以及 21 个 E2E 旅程清单如何像真实用户一样操作桌面应用——从配置细节到本地运行命令新手照做即可上手。三层测试体系总览单元、集成、E2E 各管什么Whiteboard 的仓库由 pnpm monorepo 组织测试按离真实用户多远分成三层层级运行器覆盖范围核心配置单元/组件VitestNode 浏览器双项目模块逻辑、React 组件、画布渲染vitest.config.ts集成Vitest integration 配置JSON API、diffr 运行时vitest.integration.config.ts 同目录端到端自研 journey harness Playwright CDP完整桌面应用、CLI、语言服务run.mjsVitest 浏览器模式配置Chromium 无头 DOM 测试是怎么跑起来的打开 vitest.config.ts会发现它定义了两个并行项目projects这是整个浏览器测试的骨架canvas-node 项目Node 环境下跑模块图environment: node排除所有*.browser.test.{ts,tsx}文件超时放宽到 15 秒适配共享 CI 双核跑机负责画布中与浏览器无关的逻辑文档派生、队列调度等browser 项目真实 Chromium 里的 DOM 测试这是关键配置vitest.config.tsbrowser: { enabled: true, headless: true, provider: playwright(), instances: [{ browser: chromium }], viewport: { width: 1280, height: 900 }, screenshotFailures: true, trace: process.env.CI true ? retain-on-failure : off, },要点解读provider: playwright()chromiumVitest 浏览器模式不是用 jsdom 模拟 DOM而是通过 Playwright 启动真正的 Chromium 无头浏览器React 组件在真实渲染管线里运行能发现样式、布局、字体、动画这类 jsdom 测不出来的问题screenshotFailures: true任何断言失败自动截图失败现场一图可见CI 上trace: retain-on-failure失败时保留 Vitest trace方便事后回放每一步操作1280×900 固定视口保证每次渲染结果可复现。浏览器测试文件的命名约定*.browser.test.tsx这个后缀是路由开关只有匹配src/**/*.browser.test.{ts,tsx}的文件才进 browser 项目其余全部留在 Node 项目。以 draw-queue.browser.test.tsx 为例它在 Chromium 里挂载真实的ApiDocument画布组件验证流程图块逐帧绘制的行为。每个测试页的清场与样式注入browser-test-setup.ts 是 browser 项目的 setup 文件做了三件贴心事打开 React 的IS_REACT_ACT_ENVIRONMENT标志让act()正常工作每个测试后清空document.body、localStorage、sessionStorage杜绝测试间污染把 StyleX 收集到的 CSS 从/virtual:stylex.css端点一次性注入head——这正是生产构建放置规则的位置保证测到的样式与线上一致。上图就是这类浏览器测试产出的画面Chromium 里渲染出的评审画布流程图节点上的0 −3标注正等待断言校验。集成测试层为重的依赖单独立门不是所有测试都能 5 秒内跑完。vitest.integration.config.ts 单独圈出scripts/*.integration.mjs与src/review-api/*.integration.ts把testTimeout放宽到 30 秒、hookTimeout到 60 秒且maxWorkers: 1串行执行避免多 worker 抢 CPU。对应脚本见 package.json例如test:integration:diffr会先构建工作区依赖、再运行集成用例。E2E 旅程清单21 个端到端场景逐一拆解E2E 层位于 apps/review-desktop/scripts/e2e/官方说明在 TESTING.md。旅程journey的工作方式每个journeys/*.mjs文件都独立启动一次 Whiteboard Desktop隔离的 review home、独立 profile、独立远程调试端口和临时目录然后通过三条通道驱动它——JSON review API、已安装的whiteboardCLI、以及 Playwright over CDP。harness 提供的常用工具harness.mjs、TESTING.md包括until轮询等待条件成立api/apiOk调用 JSON review APIcli/cliRaw执行已安装 CLIcheck记录该旅程证明了什么写入report.jsonrestartDesktop重启桌面端支持 SIGKILL 模拟崩溃knownBug标记已知缺陷下文细讲。21 个旅程清单速查旅程名验证内容阶段first-run遥测通知、新手引导栏、社区邀请只出现一次1canvas-resume画布恢复、Trace 视图、软件图定位1diagram-persistence流程图编辑持久化1editor-persistence编辑器内容持久化1find-peek-performance查找与 peek 的响应性能1home-multi-review首页多评审的管理与撤销1json-api-edit通过 JSON API 编辑文档1legacy-import旧格式评审导入迁移1math-renderingLaTeX 数学公式渲染边界1reader-navigation阅读模式导航1settings-and-migration设置项与存储迁移1shared-review共享评审流程1telemetry-contract遥测上报契约与网络策略1tutorial新手教程逐步引导1worktree-drift仓库目录被移动/删除后的降级1cli-desktop-edgesCLI 与桌面端交互边界1lsp-typescriptTS 悬停、Go to Definition1lsp-pythonPython 语言服务1lsp-goGo 语言服务需联网下载工具链2lsp-rustrust-analyzer 启动与竞争条件2diffr-settingsdiffr 渲染配置1阶段说明Phase 1 全程离线首次会拉取精选 VSIX 缓存Phase 2 的lsp-go、lsp-rust需下载工具链只有设置REVIEW_E2E_NETWORK1才运行。拿 first-run.mjs 为例它用精确文本断言遥测通知出现、点击Open Settings后落在隐私行、用两个评审触发社区邀请、再重启两次确认不再打扰被持久化——每一步都有ctx.check(...)记录证据。KNOWN_BUGS.md从不弱化断言的已知缺陷台账E2E 套件发现的产品 bug 全部登记在 KNOWN_BUGS.md规则非常强硬旅程绝不为通过而弱化断言先断言真实行为、再佐证 bug 自身特征然后调用ctx.knownBug(标题)harness 会校验该标题必须存在于台账中否则旅程直接失败。这意味着 bug 修复当天对应旅程会自动由预期失败翻转为通过形成闭环。台账里每条记录都带 Journey、发现日期、复现步骤、期望/实际行为与file:line级根因分析本身就是很好的调试范本。如何本地运行 Whiteboard 测试命令速查命令作用pnpm --filter dev.fast/review test运行 Node 模块图层全部用例pnpm --filter dev.fast/review test:node只跑shared-module-graph项目pnpm --filter dev.fast/review test:integration:diffr构建依赖后跑 diffr 集成测试node apps/review-desktop/scripts/e2e/run.mjs --list仅列出全部旅程不启动应用node apps/review-desktop/scripts/e2e/run.mjs --runtime $REVIEW_E2E_RUNTIME运行全部 Phase 1 旅程node apps/review-desktop/scripts/e2e/run.mjs --journey first-run --runtime ...只跑指定旅程REVIEW_E2E_NETWORK1附加变量解锁 Phase 2Go/Rust旅程运行 E2E 前需按 TESTING.md 构建 Desktop 并暂存一个生产版 CLI 运行时--runtime必须指向已安装包而非源码 checkout。每个旅程在临时目录留下report.json、app.log失败时还有failure.png与failure-dom.txt——排查三步曲看 check 记录 → 看失败截图 → 对照 app.log。总结这套测试体系最值得借鉴的 5 个设计浏览器测试用真浏览器Vitest 浏览器模式 Playwright Chromium杜绝 jsdom 假象文件后缀即路由*.browser.test.tsx一个约定划分 Node 与浏览器两类用例失败自带现场screenshotFailures CI trace 旅程级failure.png排障不靠猜旅程隔离彻底每个旅程独立 home、profile、端口、临时目录可任意重跑已知缺陷闭环管理KNOWN_BUGS.md标题即断言锚点修好 bug 当天测试自动转绿。对想给自家桌面/画布类应用建测试体系的同学来说vitest.config.ts 的双项目配置与 TESTING.md 的旅程规范是最值得先抄的两份作业。【免费下载链接】whiteboardopen-source canvas for thoughtful software design项目地址: https://gitcode.com/gh_mirrors/whiteboard36/whiteboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考