Cypress 如何用 test-binary 编写运行在 Docker 中的二进制系统测试【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress如果你已经在 Cypress 仓库里写过系统测试但发现它们跑在“未构建的 App”上测不到真实的 NPM 包安装流程和产线二进制行为那么你需要的是system-tests/test-binary目录下的二进制系统测试。这类测试针对已构建的 Cypress App每个用例在自己的 Docker 容器里运行容器内先npm install生产版 CLI 和构建好的 Cypress.zip再用真实的cypress run命令执行测试项目。它的目标是覆盖普通system-tests覆盖不到的场景不同 Node 版本、有/没有 Xvfb、不同操作系统版本。test 与 test-binary先确认你在写哪一类测试system-tests/README.md 把系统测试分成两部分./test目录下的 spec 跑在未构建的 Cypress App 上不测试cypressNPM 包的安装或其他产线 App 行为目的是让 CI 尽量快./test-binary目录下的 spec 跑在已构建的 Cypress App 上并且每个用例运行在独立的 Docker 容器中得到一个干净的环境。README 的原话是在这些测试里运行一个项目与在 CI 的 Docker 中运行真实的生产版 Cypress之间“应该没有任何功能差异”。两类 spec 都由 Mocha wrappersystemTests驱动配套一个位于./projects的自包含 Cypress 测试项目。二进制测试在 CI 中属于binary-system-tests作业家族。前置条件先构建 cypress.zip 和 CLIDocker 测试的前提是仓库里已经存在两个构建产物。system-tests/lib/docker.ts 中的checkBuiltBinary会在每次 Docker 测试启动前检查缺失时直接抛出以下错误Expected built cypress.zip at project root. Run yarn binary-build, yarn binary-package, and yarn binary-zip. Expected built CLI in /cli/build. Run yarn build in cli.也就是说在写测试之前需要在仓库根目录依次执行yarn binary-build、yarn binary-package、yarn binary-zip产出根目录的cypress.zip进入cli包执行yarn build产出cli/build目录。此外测试机需要本地可用的 Dockerharness 会拉取你指定的镜像并在容器里执行命令。编写第一个 test-binary specREADME 给出的最小示例如下保存在./test-binary/下即可// ./test-binary/node-versions.spec.ts import systemTests from ../lib/system-tests import Fixtures from ../lib/fixtures describe(node versions, () { systemTests.it(runs in node 12, { dockerImage: cypress:node/12, project: todos, withBinary: true, }) })其中dockerImage指定容器镜像project指向system-tests/projects下的自包含项目如todos其tests/目录含 spec 文件withBinary: true表示使用构建好的二进制。仓库中现成的 spec 展示了更多可组合的选项均位于 system-tests/test-binary// system-tests/test-binary/ci_environments_spec.ts节选 function smokeTestDockerImage (title: string, dockerImage: string, expectedExitCode: number, onRun?: ItOptions[onRun]) { systemTests.it(title, { withBinary: true, browser: electron, dockerImage, spec: test1.js, specDir: tests, project: todos, expectedExitCode, onRun, }) } describe(e2e binary CI environments, () { smokeTestDockerImage( bare node image fails (lacks xvfb), node:24, 1, async (exec) { const { stdout } await exec() expect(stdout).to.include(Your system is missing the dependency: Xvfb) }, ) smokeTestDockerImage( ubuntu 22 passes, cypress/base-internal:ubuntu22-node24, 0, ) })常用的选项组合选项用途仓库中的实例spec/specDir指定容器内要运行的 spec 文件与目录ci_environments_spec.ts中spec: test1.js,specDir: teststestingType区分 e2e 与 component 测试node_versions_node22_spec.ts 同一镜像各跑一次expectedExitCode断言cypress run的退出码0 表示通过缺 Xvfb 的裸node:24镜像预期为 1onRun拿到容器执行的stdout做断言上文对Your system is missing the dependency: Xvfb的断言command/args用自定义命令替代默认的cypressmodule_api_spec.ts 中command: yarn, args: [test]并配timeout: 240000browser指定容器内使用的浏览器二进制测试中普遍写作electron两个硬性约束来自 system-tests/lib/system-tests.ts 与 docker.tswithBinary不能缺少dockerImage否则抛出withBinary is not supported without the use of dockerImage反向亦然Docker testing is only supported with built binaries (withBinary: true)——dockerImage只能与构建产物搭配使用。withBinary模式下容器内默认执行的就是cypress命令即真实的cypress run测试项目会被复制到一个临时目录若项目带package.jsonharness 会按 lockfile 用yarn或npm安装其node_modules。镜像列表固定、数量较多时可以先并行预拉取避免每个用例各自 pull// system-tests/test-binary/typescript_7_spec.ts import systemTests from ../lib/system-tests import { beforePrePullImages } from ../lib/docker const IMAGE cypress/base:24.0.0 beforePrePullImages([IMAGE]) describe(typescript 7, () { systemTests.it(can run a typescript 7 project in ${IMAGE}, { withBinary: true, browser: electron, dockerImage: IMAGE, project: ts-proj-7, }) })beforePrePullImages在before钩子里并行pull所有镜像使后续按用例的 pull 命中本地缓存拉取超时受SYSTEM_TEST_TIMEOUT环境变量控制默认 120000 毫秒。容器内实际发生了什么指定dockerImage后docker.ts 的dockerSpawner会再次确认cypress.zip与cli/build/package.json存在对测试项目目录执行chmod -R 0777README 之外的注释说明这是为了避免 Docker 权限问题拉取镜像并以bash为 entrypoint 启动容器AutoRemove: true、Privileged: true把仓库根目录绑定到容器内的/cypress并把临时目录映射到相同绝对路径以便在测试里推理路径DISPLAY、USER、HOME、USERNAME、PATH以及npm_前缀的宿主环境变量不会被透传进容器容器内执行的入口是 system-tests/scripts/bootstrap-docker-container.sh它先校验TEST_PROJECT_DIR与REPO_DIR缺失即退出 1然后export CYPRESS_INSTALL_BINARY$ZIP_PATH # $REPO_DIR/cypress.zip export CYPRESS_CACHE_FOLDER/tmp/CYPRESS_CACHE_FOLDER/ npx npm8 install --unsafe-perm --allow-root --force file:$CLI_PATH # $REPO_DIR/cli/build cypress install也就是说容器里安装的是“生产版 CLI 构建好的二进制 zip”。脚本还支持两种可选分支当USE_YARN_TO_INSTALL_CYPRESS_BINARYtrue时改用yarn add cypressfile:$TARBALL_PATH并显式执行yarn cypress install因为 Yarn Berry 默认关闭 enableScriptspostinstall 解包步骤会被跳过当USE_BUN_TO_INSTALL_CYPRESS_BINARYtrue时改用bun add cypressfile:$TARBALL_PATH。 5. 最后执行传入的测试命令并保存其退出码作为容器退出码随后rm -rf $TEST_PROJECT_DIR删除容器内的临时项目副本注释说明这是为了避免宿主机上的权限问题。运行与验证在system-tests包内按 spec 文件名模式运行package.json 的test脚本为node ./scripts/run.js --glob-in-dir{test,test-binary}会同时覆盖两个目录yarn test node-versionsREADME 的例子运行yarn test node-versions会为cypress:node/12镜像启动本地 Docker 容器从../cypress.zip与../cli/build安装 Cypress然后在容器内调用常规的cypress run命令onRun、expectedExitCode等其他systemTests.it选项照常生效。验证方式有两层退出码expectedExitCode: 0表示容器内cypress run成功。ci_environments_spec.ts里 ubuntu 22/24 基础镜像的预期就是 0。stdout 断言通过onRun钩子检查输出例如对裸node:24镜像预期失败退出码 1且 stdout 包含Your system is missing the dependency: Xvfb。这条用例同时验证了“缺 Xvfb 会失败”这一边界。需要更新快照时在任何测试命令前加SNAPSHOT_UPDATE1见 README 的 Updating Snapshots 一节。限制与边界Docker 测试只支持构建产物想跑未构建 App 的快速回归请留在./test目录不要加dockerImage。withBinary与dockerImage必须成对出现单独使用任一项都会直接报错。容器内安装 CLI 的默认分支走npx npm8 install --unsafe-perm --allow-root --forceyarn/bun 分支由上述环境变量显式开启属于可选路径。结尾的rm -rf只删除容器内复制出来的临时项目目录用于规避宿主权限问题宿主仓库本身不受影响。CI 中这些测试归属binary-system-tests作业与常规system-tests作业分开调度。【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cypress 如何用 test-binary 编写运行在 Docker 中的二进制系统测试
Cypress 如何用 test-binary 编写运行在 Docker 中的二进制系统测试【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress如果你已经在 Cypress 仓库里写过系统测试但发现它们跑在“未构建的 App”上测不到真实的 NPM 包安装流程和产线二进制行为那么你需要的是system-tests/test-binary目录下的二进制系统测试。这类测试针对已构建的 Cypress App每个用例在自己的 Docker 容器里运行容器内先npm install生产版 CLI 和构建好的 Cypress.zip再用真实的cypress run命令执行测试项目。它的目标是覆盖普通system-tests覆盖不到的场景不同 Node 版本、有/没有 Xvfb、不同操作系统版本。test 与 test-binary先确认你在写哪一类测试system-tests/README.md 把系统测试分成两部分./test目录下的 spec 跑在未构建的 Cypress App 上不测试cypressNPM 包的安装或其他产线 App 行为目的是让 CI 尽量快./test-binary目录下的 spec 跑在已构建的 Cypress App 上并且每个用例运行在独立的 Docker 容器中得到一个干净的环境。README 的原话是在这些测试里运行一个项目与在 CI 的 Docker 中运行真实的生产版 Cypress之间“应该没有任何功能差异”。两类 spec 都由 Mocha wrappersystemTests驱动配套一个位于./projects的自包含 Cypress 测试项目。二进制测试在 CI 中属于binary-system-tests作业家族。前置条件先构建 cypress.zip 和 CLIDocker 测试的前提是仓库里已经存在两个构建产物。system-tests/lib/docker.ts 中的checkBuiltBinary会在每次 Docker 测试启动前检查缺失时直接抛出以下错误Expected built cypress.zip at project root. Run yarn binary-build, yarn binary-package, and yarn binary-zip. Expected built CLI in /cli/build. Run yarn build in cli.也就是说在写测试之前需要在仓库根目录依次执行yarn binary-build、yarn binary-package、yarn binary-zip产出根目录的cypress.zip进入cli包执行yarn build产出cli/build目录。此外测试机需要本地可用的 Dockerharness 会拉取你指定的镜像并在容器里执行命令。编写第一个 test-binary specREADME 给出的最小示例如下保存在./test-binary/下即可// ./test-binary/node-versions.spec.ts import systemTests from ../lib/system-tests import Fixtures from ../lib/fixtures describe(node versions, () { systemTests.it(runs in node 12, { dockerImage: cypress:node/12, project: todos, withBinary: true, }) })其中dockerImage指定容器镜像project指向system-tests/projects下的自包含项目如todos其tests/目录含 spec 文件withBinary: true表示使用构建好的二进制。仓库中现成的 spec 展示了更多可组合的选项均位于 system-tests/test-binary// system-tests/test-binary/ci_environments_spec.ts节选 function smokeTestDockerImage (title: string, dockerImage: string, expectedExitCode: number, onRun?: ItOptions[onRun]) { systemTests.it(title, { withBinary: true, browser: electron, dockerImage, spec: test1.js, specDir: tests, project: todos, expectedExitCode, onRun, }) } describe(e2e binary CI environments, () { smokeTestDockerImage( bare node image fails (lacks xvfb), node:24, 1, async (exec) { const { stdout } await exec() expect(stdout).to.include(Your system is missing the dependency: Xvfb) }, ) smokeTestDockerImage( ubuntu 22 passes, cypress/base-internal:ubuntu22-node24, 0, ) })常用的选项组合选项用途仓库中的实例spec/specDir指定容器内要运行的 spec 文件与目录ci_environments_spec.ts中spec: test1.js,specDir: teststestingType区分 e2e 与 component 测试node_versions_node22_spec.ts 同一镜像各跑一次expectedExitCode断言cypress run的退出码0 表示通过缺 Xvfb 的裸node:24镜像预期为 1onRun拿到容器执行的stdout做断言上文对Your system is missing the dependency: Xvfb的断言command/args用自定义命令替代默认的cypressmodule_api_spec.ts 中command: yarn, args: [test]并配timeout: 240000browser指定容器内使用的浏览器二进制测试中普遍写作electron两个硬性约束来自 system-tests/lib/system-tests.ts 与 docker.tswithBinary不能缺少dockerImage否则抛出withBinary is not supported without the use of dockerImage反向亦然Docker testing is only supported with built binaries (withBinary: true)——dockerImage只能与构建产物搭配使用。withBinary模式下容器内默认执行的就是cypress命令即真实的cypress run测试项目会被复制到一个临时目录若项目带package.jsonharness 会按 lockfile 用yarn或npm安装其node_modules。镜像列表固定、数量较多时可以先并行预拉取避免每个用例各自 pull// system-tests/test-binary/typescript_7_spec.ts import systemTests from ../lib/system-tests import { beforePrePullImages } from ../lib/docker const IMAGE cypress/base:24.0.0 beforePrePullImages([IMAGE]) describe(typescript 7, () { systemTests.it(can run a typescript 7 project in ${IMAGE}, { withBinary: true, browser: electron, dockerImage: IMAGE, project: ts-proj-7, }) })beforePrePullImages在before钩子里并行pull所有镜像使后续按用例的 pull 命中本地缓存拉取超时受SYSTEM_TEST_TIMEOUT环境变量控制默认 120000 毫秒。容器内实际发生了什么指定dockerImage后docker.ts 的dockerSpawner会再次确认cypress.zip与cli/build/package.json存在对测试项目目录执行chmod -R 0777README 之外的注释说明这是为了避免 Docker 权限问题拉取镜像并以bash为 entrypoint 启动容器AutoRemove: true、Privileged: true把仓库根目录绑定到容器内的/cypress并把临时目录映射到相同绝对路径以便在测试里推理路径DISPLAY、USER、HOME、USERNAME、PATH以及npm_前缀的宿主环境变量不会被透传进容器容器内执行的入口是 system-tests/scripts/bootstrap-docker-container.sh它先校验TEST_PROJECT_DIR与REPO_DIR缺失即退出 1然后export CYPRESS_INSTALL_BINARY$ZIP_PATH # $REPO_DIR/cypress.zip export CYPRESS_CACHE_FOLDER/tmp/CYPRESS_CACHE_FOLDER/ npx npm8 install --unsafe-perm --allow-root --force file:$CLI_PATH # $REPO_DIR/cli/build cypress install也就是说容器里安装的是“生产版 CLI 构建好的二进制 zip”。脚本还支持两种可选分支当USE_YARN_TO_INSTALL_CYPRESS_BINARYtrue时改用yarn add cypressfile:$TARBALL_PATH并显式执行yarn cypress install因为 Yarn Berry 默认关闭 enableScriptspostinstall 解包步骤会被跳过当USE_BUN_TO_INSTALL_CYPRESS_BINARYtrue时改用bun add cypressfile:$TARBALL_PATH。 5. 最后执行传入的测试命令并保存其退出码作为容器退出码随后rm -rf $TEST_PROJECT_DIR删除容器内的临时项目副本注释说明这是为了避免宿主机上的权限问题。运行与验证在system-tests包内按 spec 文件名模式运行package.json 的test脚本为node ./scripts/run.js --glob-in-dir{test,test-binary}会同时覆盖两个目录yarn test node-versionsREADME 的例子运行yarn test node-versions会为cypress:node/12镜像启动本地 Docker 容器从../cypress.zip与../cli/build安装 Cypress然后在容器内调用常规的cypress run命令onRun、expectedExitCode等其他systemTests.it选项照常生效。验证方式有两层退出码expectedExitCode: 0表示容器内cypress run成功。ci_environments_spec.ts里 ubuntu 22/24 基础镜像的预期就是 0。stdout 断言通过onRun钩子检查输出例如对裸node:24镜像预期失败退出码 1且 stdout 包含Your system is missing the dependency: Xvfb。这条用例同时验证了“缺 Xvfb 会失败”这一边界。需要更新快照时在任何测试命令前加SNAPSHOT_UPDATE1见 README 的 Updating Snapshots 一节。限制与边界Docker 测试只支持构建产物想跑未构建 App 的快速回归请留在./test目录不要加dockerImage。withBinary与dockerImage必须成对出现单独使用任一项都会直接报错。容器内安装 CLI 的默认分支走npx npm8 install --unsafe-perm --allow-root --forceyarn/bun 分支由上述环境变量显式开启属于可选路径。结尾的rm -rf只删除容器内复制出来的临时项目目录用于规避宿主权限问题宿主仓库本身不受影响。CI 中这些测试归属binary-system-tests作业与常规system-tests作业分开调度。【免费下载链接】cypressFast, easy and reliable testing for anything that runs in a browser.项目地址: https://gitcode.com/GitHub_Trending/cy/cypress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考