Recharts 怎么跑 Playwright 视觉回归测试Docker 镜像构建与快照更新【免费下载链接】rechartsRedefined chart library built with React and D3项目地址: https://gitcode.com/GitHub_Trending/re/recharts如果你要在 recharts 仓库里跑视觉回归Visual Regression简称 VR测试或者在改动图表组件后需要刷新基线截图那么整个流程是固定的VR 测试不在本地直接运行而是全部跑在 Docker 容器里用 Playwright 的组件测试模型加载test-vr/tests下的 story再对渲染结果做toHaveScreenshot()截图比对。之所以强制用 Docker是为了让字体、阴影、亚像素渲染在不同机器上保持一致避免环境差异造成测试抖动见 test-vr/README.md。本文覆盖从构建 Docker 镜像、运行测试、查看结果到更新快照基线的完整路径以及 Playwright 版本不匹配时的处理方式。准备条件按 DEVELOPING.md 的说明前置要求只有两项本机安装并启动 Docker。官方说法是“Playwright tests are running inside Docker. You will need to have Docker installed and running”且不需要 Docker 账号或登录。这一步只需做一次。克隆仓库并安装依赖git clone https://github.com/recharts/recharts.git cd recharts npm install # the right Node version can be found in .nvmrc fileNode 版本以.nvmrc文件为准。Windows 用户如果因为codecov/bundle-analyzer只支持 Linux/Darwin 导致npm install失败用npm install --force继续。构建 Docker 镜像构建命令是一条npm run test-vr:prepare查看 package.json 可以看到它展开为npm run build docker compose up -d --build即先构建 recharts 库再根据 docker-compose.yml 和 test-vr/playwright-ct.Dockerfile 构建镜像并后台启动容器。文档说明这一步大约需要两到三分钟。Dockerfile 基于官方 Playwright 镜像当前是mcr.microsoft.com/playwright:v1.62.1-jammy在其中执行npm install、npx playwright install --with-deps并暴露 3100gallery 开发服务器和 9323报告服务器两个端口。何时必须重新构建镜像test-vr/README.md 给了明确判断只有当你修改了package.json的依赖或要升级基础 Playwright 版本时才需要 rebuild。日常改测试文件不用重建因为 docker-compose.yml 把./src、./www、./test-vr三个目录以卷的形式挂进容器你编辑文件后下次运行立即生效。运行测试常规循环是写一个新测试、运行、修、再跑。全量运行npm run test-vr它实际执行docker compose run --rm test-vr playwright-test其中的playwright-test是 test-vr/.bin 里的便捷脚本最终等价于npx playwright test --config/recharts/test-vr/playwright.config.ts。开发阶段通常不需要全量跑。DEVELOPING.md 给出了两个缩小范围的写法# 只跑一个 spec 文件 npm run test-vr -- test-vr/tests/ThemeVariants.spec-vr.tsx # 只跑某个项目project并按标题过滤 npm run test-vr -- --projectchromium-dark --grepLineChart这里的项目对应 test-vr/playwright.config.ts 里定义的九个项目chromium、firefox、webkit三个基础项目legacy 主题加上每个浏览器各两个的-light和-dark项目。基础项目加载 gallery 时不套RechartsThemeProvider-light/-dark项目通过 URL 参数?rechartsThemelight|dark选择主题。配置里还有两个与运行方式相关的要点webServer选项会在测试前自动启动 Vite 开发服务器在 3100 端口提供 story galleryhttp://localhost:3100/gallery/index.html是 Playwright 的挂载页直接打开是空白的不是给人看的导航页CI 环境下 retries 为 2、workers 为 2且报告改用 blob reporter本地则生成 HTML 报告。如果想在界面里调试可以用 Playwright 的 UI 模式npm run test-vr:ui该命令会映射两个端口Playwright UI 在 http://localhost:8080Vite gallery 服务器保持在 3100 端口。运行期间可以直接打开 http://localhost:3100/gallery/preview.html 手动浏览 story预览页会把选中的 story 以默认 props 分别挂载到 legacy、light、dark 三个隔离面板里。注意/gallery/index.html本身没有导航不要对它抱期待。查看测试结果测试跑完后在浏览器打开 http://localhost:9323 即可看到 HTML 报告。这一点容易被误导CLI 在测试结束时会提示你去运行 “show-report”但 DEVELOPING.md 明确说这一步是不必要的——docker-compose.yml 里的容器本身就常驻一个npx playwright show-report /recharts/test-vr/playwright-report --host 0.0.0.0 --port 9323进程报告直接可访问。playwright-report是自动生成的、人类可读的 HTML 报告内容随每次运行变化不应提交进仓库test-results是原始结果目录供 HTML reporter 使用同样不提交。更新快照基线基线截图snapshot存放在test-vr/__snapshots__目录test-vr/README.md 强调这个文件夹要提交到仓库它就是视觉回归的基准。确认截图变化是预期的之后更新快照npm run test-vr:update这条命令等价于docker compose run --rm test-vr playwright-test --update-snapshots changed即只更新与基线有差异的截图。做定点迁移或局部更新时可以只限定受影响的 spec 和项目集npm run test-vr:update -- test-vr/tests/ThemeVariants.spec-vr.tsx npm run test-vr:update -- --projectchromium-light --grepLineChart更新完之后按 DEVELOPING.md 的要求处理提交范围把test-vr/__snapshots__里有意新增或修改的文件提交进去test-results和playwright-report两个目录不要提交。快照的命名规则由项目名决定例如LineChart-1-chromium-light-linux.png——这正是 README 强调“不要把主题写进 story props、测试标题或自定义截图名”的原因项目名称天然让不同主题/浏览器的快照分离且确定。新测试与主题的写法约定写新 spec 时要符合现有约定否则快照会进错项目。新 VR spec 应从 test-vr/tests/fixtures.ts 导入testWithThemes而不是旧的test导出import { expect, testWithThemes } from ./fixtures; testWithThemes(LineChart, async ({ mountStory }) { const component await mountStory(App/LineChart); await expect(component).toHaveScreenshot(); });测试不直接挂 JSXJSX 写在同目录的*.story.tsx文件的具名导出里spec 通过 story idstory 文件在test-vr/tests/下的路径去掉.story.tsx后缀再加导出名挂载。mountStory包装了 Playwright 内置的mount()保证toHaveScreenshot()截取同一边界框。旧的test导出是 legacy-only 的暂存 fixture只保留当前仅浏览器维度的快照命名给尚未迁移的存量 spec 用存量 spec 要等各自的迁移补齐 light/dark 基线后才能升级迁移前不应为它们生成新的主题快照。需要抑制个别主题变体时用testWithThemes.use({ rechartsThemes: [legacy, light] })或recharts-theme-legacy、recharts-theme-light、recharts-theme-dark标签这些只控制 Recharts 主题与 Playwright 的colorScheme控制浏览器prefers-color-scheme是两个独立维度。Playwright 版本不匹配的排查文档记载的一个典型报错是browserType.launch: Executable doesnt exist当playwright包版本与 Docker 镜像里的版本不一致时出现报错信息形如文档示例Error: browserType.launch: Executable doesnt exist at /ms-playwright/webkit-2191/pw_run.sh ║ Looks like Playwright Test or Playwright was just updated to 1.54.1. ║ ║ - current: mcr.microsoft.com/playwright:v1.44.0-jammy ║ ║ - required: mcr.microsoft.com/playwright:v1.54.1-jammy ║处理方式编辑 test-vr/playwright-ct.Dockerfile把FROM字段改成报错中推荐的基础镜像版本然后重新构建镜像回到npm run test-vr:prepare或docker compose up -d --build。版本一致性还有校验机制scripts/check-playwright-versions.mjs 会对比四处声明的 Playwright 版本——package.json里的playwright与playwright/test、test-vr/playwright-ct.Dockerfile的FROM镜像版本、.github/workflows/ci.yml中的镜像版本——全部一致才通过否则打印各来源的版本号并以非零码退出。所以如果你升级了其中任何一处其余三处也要同步改。容器内调试测试跑起来之后排查手段按 test-vr/README.md 的说明所有镜像和容器都可以通过 Docker Desktop 或docker ps -a等常规命令查看在容器里执行任意命令docker compose run test-vr command容器退出后想再进去看现场可以用下面两条命令把容器固化成镜像再启动这会在本机创建一个名为debug的镜像和一个临时容器docker commit container_id debug docker run -it --rm debug bashcontainer_id用docker ps -a查到的实际容器 id 替换。小结一次完整的最小路径把上面的路径串起来最小闭环是确认 Docker 运行中npm run test-vr:prepare构建镜像依赖变更后必须重跑npm run test-vr -- spec 文件跑目标测试打开 http://localhost:9323 看报告确认失败项是否属于预期变化属于预期变化时用npm run test-vr:update -- spec 文件定点刷新基线提交test-vr/__snapshots__中的变更不提交test-results与playwright-report升级 Playwright 时同步package.json、Dockerfile、CI 工作流三处版本让 scripts/check-playwright-versions.mjs 的校验通过。【免费下载链接】rechartsRedefined chart library built with React and D3项目地址: https://gitcode.com/GitHub_Trending/re/recharts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Recharts 怎么跑 Playwright 视觉回归测试？Docker 镜像构建与快照更新
Recharts 怎么跑 Playwright 视觉回归测试Docker 镜像构建与快照更新【免费下载链接】rechartsRedefined chart library built with React and D3项目地址: https://gitcode.com/GitHub_Trending/re/recharts如果你要在 recharts 仓库里跑视觉回归Visual Regression简称 VR测试或者在改动图表组件后需要刷新基线截图那么整个流程是固定的VR 测试不在本地直接运行而是全部跑在 Docker 容器里用 Playwright 的组件测试模型加载test-vr/tests下的 story再对渲染结果做toHaveScreenshot()截图比对。之所以强制用 Docker是为了让字体、阴影、亚像素渲染在不同机器上保持一致避免环境差异造成测试抖动见 test-vr/README.md。本文覆盖从构建 Docker 镜像、运行测试、查看结果到更新快照基线的完整路径以及 Playwright 版本不匹配时的处理方式。准备条件按 DEVELOPING.md 的说明前置要求只有两项本机安装并启动 Docker。官方说法是“Playwright tests are running inside Docker. You will need to have Docker installed and running”且不需要 Docker 账号或登录。这一步只需做一次。克隆仓库并安装依赖git clone https://github.com/recharts/recharts.git cd recharts npm install # the right Node version can be found in .nvmrc fileNode 版本以.nvmrc文件为准。Windows 用户如果因为codecov/bundle-analyzer只支持 Linux/Darwin 导致npm install失败用npm install --force继续。构建 Docker 镜像构建命令是一条npm run test-vr:prepare查看 package.json 可以看到它展开为npm run build docker compose up -d --build即先构建 recharts 库再根据 docker-compose.yml 和 test-vr/playwright-ct.Dockerfile 构建镜像并后台启动容器。文档说明这一步大约需要两到三分钟。Dockerfile 基于官方 Playwright 镜像当前是mcr.microsoft.com/playwright:v1.62.1-jammy在其中执行npm install、npx playwright install --with-deps并暴露 3100gallery 开发服务器和 9323报告服务器两个端口。何时必须重新构建镜像test-vr/README.md 给了明确判断只有当你修改了package.json的依赖或要升级基础 Playwright 版本时才需要 rebuild。日常改测试文件不用重建因为 docker-compose.yml 把./src、./www、./test-vr三个目录以卷的形式挂进容器你编辑文件后下次运行立即生效。运行测试常规循环是写一个新测试、运行、修、再跑。全量运行npm run test-vr它实际执行docker compose run --rm test-vr playwright-test其中的playwright-test是 test-vr/.bin 里的便捷脚本最终等价于npx playwright test --config/recharts/test-vr/playwright.config.ts。开发阶段通常不需要全量跑。DEVELOPING.md 给出了两个缩小范围的写法# 只跑一个 spec 文件 npm run test-vr -- test-vr/tests/ThemeVariants.spec-vr.tsx # 只跑某个项目project并按标题过滤 npm run test-vr -- --projectchromium-dark --grepLineChart这里的项目对应 test-vr/playwright.config.ts 里定义的九个项目chromium、firefox、webkit三个基础项目legacy 主题加上每个浏览器各两个的-light和-dark项目。基础项目加载 gallery 时不套RechartsThemeProvider-light/-dark项目通过 URL 参数?rechartsThemelight|dark选择主题。配置里还有两个与运行方式相关的要点webServer选项会在测试前自动启动 Vite 开发服务器在 3100 端口提供 story galleryhttp://localhost:3100/gallery/index.html是 Playwright 的挂载页直接打开是空白的不是给人看的导航页CI 环境下 retries 为 2、workers 为 2且报告改用 blob reporter本地则生成 HTML 报告。如果想在界面里调试可以用 Playwright 的 UI 模式npm run test-vr:ui该命令会映射两个端口Playwright UI 在 http://localhost:8080Vite gallery 服务器保持在 3100 端口。运行期间可以直接打开 http://localhost:3100/gallery/preview.html 手动浏览 story预览页会把选中的 story 以默认 props 分别挂载到 legacy、light、dark 三个隔离面板里。注意/gallery/index.html本身没有导航不要对它抱期待。查看测试结果测试跑完后在浏览器打开 http://localhost:9323 即可看到 HTML 报告。这一点容易被误导CLI 在测试结束时会提示你去运行 “show-report”但 DEVELOPING.md 明确说这一步是不必要的——docker-compose.yml 里的容器本身就常驻一个npx playwright show-report /recharts/test-vr/playwright-report --host 0.0.0.0 --port 9323进程报告直接可访问。playwright-report是自动生成的、人类可读的 HTML 报告内容随每次运行变化不应提交进仓库test-results是原始结果目录供 HTML reporter 使用同样不提交。更新快照基线基线截图snapshot存放在test-vr/__snapshots__目录test-vr/README.md 强调这个文件夹要提交到仓库它就是视觉回归的基准。确认截图变化是预期的之后更新快照npm run test-vr:update这条命令等价于docker compose run --rm test-vr playwright-test --update-snapshots changed即只更新与基线有差异的截图。做定点迁移或局部更新时可以只限定受影响的 spec 和项目集npm run test-vr:update -- test-vr/tests/ThemeVariants.spec-vr.tsx npm run test-vr:update -- --projectchromium-light --grepLineChart更新完之后按 DEVELOPING.md 的要求处理提交范围把test-vr/__snapshots__里有意新增或修改的文件提交进去test-results和playwright-report两个目录不要提交。快照的命名规则由项目名决定例如LineChart-1-chromium-light-linux.png——这正是 README 强调“不要把主题写进 story props、测试标题或自定义截图名”的原因项目名称天然让不同主题/浏览器的快照分离且确定。新测试与主题的写法约定写新 spec 时要符合现有约定否则快照会进错项目。新 VR spec 应从 test-vr/tests/fixtures.ts 导入testWithThemes而不是旧的test导出import { expect, testWithThemes } from ./fixtures; testWithThemes(LineChart, async ({ mountStory }) { const component await mountStory(App/LineChart); await expect(component).toHaveScreenshot(); });测试不直接挂 JSXJSX 写在同目录的*.story.tsx文件的具名导出里spec 通过 story idstory 文件在test-vr/tests/下的路径去掉.story.tsx后缀再加导出名挂载。mountStory包装了 Playwright 内置的mount()保证toHaveScreenshot()截取同一边界框。旧的test导出是 legacy-only 的暂存 fixture只保留当前仅浏览器维度的快照命名给尚未迁移的存量 spec 用存量 spec 要等各自的迁移补齐 light/dark 基线后才能升级迁移前不应为它们生成新的主题快照。需要抑制个别主题变体时用testWithThemes.use({ rechartsThemes: [legacy, light] })或recharts-theme-legacy、recharts-theme-light、recharts-theme-dark标签这些只控制 Recharts 主题与 Playwright 的colorScheme控制浏览器prefers-color-scheme是两个独立维度。Playwright 版本不匹配的排查文档记载的一个典型报错是browserType.launch: Executable doesnt exist当playwright包版本与 Docker 镜像里的版本不一致时出现报错信息形如文档示例Error: browserType.launch: Executable doesnt exist at /ms-playwright/webkit-2191/pw_run.sh ║ Looks like Playwright Test or Playwright was just updated to 1.54.1. ║ ║ - current: mcr.microsoft.com/playwright:v1.44.0-jammy ║ ║ - required: mcr.microsoft.com/playwright:v1.54.1-jammy ║处理方式编辑 test-vr/playwright-ct.Dockerfile把FROM字段改成报错中推荐的基础镜像版本然后重新构建镜像回到npm run test-vr:prepare或docker compose up -d --build。版本一致性还有校验机制scripts/check-playwright-versions.mjs 会对比四处声明的 Playwright 版本——package.json里的playwright与playwright/test、test-vr/playwright-ct.Dockerfile的FROM镜像版本、.github/workflows/ci.yml中的镜像版本——全部一致才通过否则打印各来源的版本号并以非零码退出。所以如果你升级了其中任何一处其余三处也要同步改。容器内调试测试跑起来之后排查手段按 test-vr/README.md 的说明所有镜像和容器都可以通过 Docker Desktop 或docker ps -a等常规命令查看在容器里执行任意命令docker compose run test-vr command容器退出后想再进去看现场可以用下面两条命令把容器固化成镜像再启动这会在本机创建一个名为debug的镜像和一个临时容器docker commit container_id debug docker run -it --rm debug bashcontainer_id用docker ps -a查到的实际容器 id 替换。小结一次完整的最小路径把上面的路径串起来最小闭环是确认 Docker 运行中npm run test-vr:prepare构建镜像依赖变更后必须重跑npm run test-vr -- spec 文件跑目标测试打开 http://localhost:9323 看报告确认失败项是否属于预期变化属于预期变化时用npm run test-vr:update -- spec 文件定点刷新基线提交test-vr/__snapshots__中的变更不提交test-results与playwright-report升级 Playwright 时同步package.json、Dockerfile、CI 工作流三处版本让 scripts/check-playwright-versions.mjs 的校验通过。【免费下载链接】rechartsRedefined chart library built with React and D3项目地址: https://gitcode.com/GitHub_Trending/re/recharts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考