Compiler Explorer 的 Vitest 测试速查从 Jest 迁移到 Vitest 的编写与运行实践【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址: https://gitcode.com/gh_mirrors/co/compiler-explorerCompiler ExplorerCE将测试框架从 Jest 全面切换到 Vitest并为此整理了官方速查笔记见仓库 docs/VitestCribSheet.md。本文以该速查文档为骨架结合仓库中真实的vitest.config.ts、package.json脚本与测试用例讲解如何在 CE 仓库中运行测试、如何按 Vitest 规范编写单元测试以及后端/前端两套测试项目是如何被组织的。读完本文你将能够直接上手编写并运行 CE 的 Vitest 用例也能把同样的模式迁移到自己的 TypeScript 项目中。背景为什么 CE 切换到 Vitest原速查文档开篇即说明We just moved to a new testing framework,vitest——Compiler Explorer 已正式完成从 Jest 到 Vitest 的迁移。从仓库依赖可以看出Vitest 生态已全面落地开发依赖中同时包含vitest与vitest/coverage-v8见 package.jsonpackage.json中的测试脚本全部改为调用vitest run或vitest见 package.json覆盖率的 provider 采用 V8 引擎见 vitest.config.ts。迁移后测试 APIdescribe、it、expect与 Jest 高度兼容绝大部分既有用例只需调整导入来源即可继续工作这也是速查文档能如此简短的原因团队只需要记住从哪里导入、命令叫什么。运行测试三条核心命令速查文档给出了三条最常用的命令全部来自 package.json 中定义的 npm scripts命令作用npm test运行全部测试等价于vitest runnpm run test:watch启动监听模式先跑一遍全部测试之后监听文件变化并只重新运行发生变更的测试npm run test:watch path同上但只针对指定路径运行速查文档特别指出watch 模式much quicker as a lot of the work is cached——因为 Vitest 内置了转换缓存与模块图复用变更感知change detection让重跑范围被压缩到最小这是它比全量重跑更快的关键原因。而test:watch path则允许你把范围进一步收窄到单个文件或目录例如npm run test:watch test/utils-tests.ts除了速查文档提到的三条命令仓库还提供了几条补充脚本用于更细分的测试场景npm run test-coverage等价于vitest run --coverage基于 v8 生成文本、JSON、HTML 三种格式的覆盖率报告见 vitest.config.ts 与 package.jsonnpm run test-min以cross-env SKIP_EXPENSIVE_TESTStrue vitest run运行跳过耗时用例适合快速回归见 package.jsonnpm run test:props仅运行properties-validation-tests.ts专门校验etc/config下各语言.properties配置见 package.json。测试项目的组织结构一个配置、两个 projectVitest 采用 projects早期版本称 workspace机制将仓库测试划分为两个独立的运行单元配置集中在 vitest.config.tsunit后端单元测试include为test/**/*.ts排除test/_*.ts与test/utils.tssetupFiles注入test/_setup-fake-aws.ts与test/_setup-log.tsfrontend unit前端单元测试include为static/tests/**/*.ts排除static/tests/_*.tssetupFiles注入static/tests/_setup-dom.ts且environment指定为happy-dom。这种划分与仓库的目录约定一一对应后端逻辑lib/下的编译器、执行器、配置加载等模块的测试位于 test/前端代码static/下的组件、widget、URL 序列化等的单元测试位于 static/tests/。配套的 TypeScript 检查通过 tsconfig.tests.json 覆盖test/**/*.ts。setup 文件做了什么三个 setup 文件文件名以下划线开头因此不会被当作测试用例收集分别解决不同问题test/_setup-fake-aws.ts调用fakeCredentialsForTest()为涉及 AWS SDK 的用例注入假凭据避免测试依赖真实云环境test/_setup-log.ts调用suppressConsoleLog()在测试期间静默日志输出保持测试输出的整洁定义见 lib/logger.tsstatic/tests/_setup-dom.ts为前端用例设置__webpack_public_path__并注入一个带httpRoot、staticRoot、extraOptions属性的假#configDOM 节点模拟页面启动前的前端全局配置。从源码结构可以推断前端的 DOM 依赖被刻意控制到极简程度正如 static/tests/README.md 所写这些用例super simple只用假 document 做快速校验凡是需要真实浏览器行为pug 渲染、交互流程的场景一律交给 Cypress。官方说明见 docs/internal/FrontendTesting.md其中也明确指出happy-dom仅提供extremely minimal的 DOM 模拟。Cypress 端到端用例位于 cypress/e2e/运行方式参见 docs/UsingCypress.md。编写测试从vitest导入一切速查文档的核心建议只有一句话像用 Jest 一样使用describe、it和expect但统一从vitest导入。这一点在仓库测试中得到了严格执行例如 test/utils-tests.tsimport {describe, expect, it} from vitest;再看 test/checks.tsimport {afterAll, beforeAll, describe, expect, it} from vitest;也就是说Jest 时代的jest/globals、types/jest全局类型都不再需要测试代码里只认vitest这一个导入来源。异步断言的推荐写法速查文档给出的异步断言范式是await expect(someAsyncThing()).resolves.toEqual(someValue);与之对应的失败断言是await expect(...).rejects.toThrow(...)。推荐resolves/rejects而非直接await裸 Promise 的理由很实际当断言失败时Vitest 能保留完整的 diff 信息与异步上下文错误定位更清晰且代码风格统一、可读性好。常用匹配器速查文档专门强调expectis pretty rich举了两个例子expect(x).toContain(moo); // 数组/字符串包含断言 expect(y).not.toHaveProperty(badger); // 属性不存在断言配合 .not 反转完整的匹配器列表可在 Vitest 官方 Expect API 文档中查询。仓库测试中这些匹配器被大量使用如 test/utils-tests.ts 用expect(utils.splitLines(...)).toEqual([...])做逐场景的字符串分割断言test/checks.ts 则用expect(differences).toEqual({})校验各语言.properties中声明的库与配置文件中的libs.*.name条目完全一致属于典型的仓库自洽性config drift检查。实战示例一段完整的 Vitest 用例长什么样结合 test/utils-tests.ts一个符合 CE 规范的测试块大致如下import {describe, expect, it} from vitest; import * as utils from ../lib/utils.js; describe(Splits lines, () { it(handles empty input, () { expect(utils.splitLines()).toEqual([]); }); it(handles a single line with no newline, () { expect(utils.splitLines(A line)).toEqual([A line]); }); it(handles multiple lines, () { expect(utils.splitLines(A line\nAnother line\n)).toEqual([A line, Another line]); }); it(handles \\r\\n lines, () { expect(utils.splitLines(Some\r\nLines\r\n)).toEqual([Some, Lines]); }); });可以提炼出 CE 测试编写的几条惯例一个describe对应一个被测函数/模块一个it对应一个边界场景用例命名直接描述行为handles empty inputdescribe/it块内不做多余装饰纯断言配合 setup 文件统一处理全局副作用断言优先使用toEqual而非toBe适合比较数组、对象等结构化数据涉及环境初始化/清理时使用beforeAll/afterAll如 test/checks.ts 中先properties.initialize(...)再在收尾properties.reset()。给仓库外读者的迁移建议虽然速查文档是为 CE 内部团队写的但其模式可以直接迁移到其他从 Jest 切换到 Vitest 的 TypeScript 项目将测试中的import {...} from jest/globals全部替换为from vitestdescribe/it/expect用法保持不变利用 Vitest 的projects机制把后端纯逻辑测试与前端 DOM 相关测试分开前端部分配置environment: happy-dom或jsdom用setupFiles集中处理测试环境副作用假凭据、日志静默、全局 DOM 桩让每个用例保持只有断言的干净形态把npm test定义为vitest run、test:watch定义为vitest即可获得文档中所说的缓存加速与变更感知重跑。需要注意的前提是CE 仓库要求 Node.js22.22.1见 package.jsonVitest 版本为 4.x见 package.json若你的项目版本不同配置项如projects的写法可能需要相应调整。【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址: https://gitcode.com/gh_mirrors/co/compiler-explorer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Compiler Explorer 的 Vitest 测试速查：从 Jest 迁移到 Vitest 的编写与运行实践
Compiler Explorer 的 Vitest 测试速查从 Jest 迁移到 Vitest 的编写与运行实践【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址: https://gitcode.com/gh_mirrors/co/compiler-explorerCompiler ExplorerCE将测试框架从 Jest 全面切换到 Vitest并为此整理了官方速查笔记见仓库 docs/VitestCribSheet.md。本文以该速查文档为骨架结合仓库中真实的vitest.config.ts、package.json脚本与测试用例讲解如何在 CE 仓库中运行测试、如何按 Vitest 规范编写单元测试以及后端/前端两套测试项目是如何被组织的。读完本文你将能够直接上手编写并运行 CE 的 Vitest 用例也能把同样的模式迁移到自己的 TypeScript 项目中。背景为什么 CE 切换到 Vitest原速查文档开篇即说明We just moved to a new testing framework,vitest——Compiler Explorer 已正式完成从 Jest 到 Vitest 的迁移。从仓库依赖可以看出Vitest 生态已全面落地开发依赖中同时包含vitest与vitest/coverage-v8见 package.jsonpackage.json中的测试脚本全部改为调用vitest run或vitest见 package.json覆盖率的 provider 采用 V8 引擎见 vitest.config.ts。迁移后测试 APIdescribe、it、expect与 Jest 高度兼容绝大部分既有用例只需调整导入来源即可继续工作这也是速查文档能如此简短的原因团队只需要记住从哪里导入、命令叫什么。运行测试三条核心命令速查文档给出了三条最常用的命令全部来自 package.json 中定义的 npm scripts命令作用npm test运行全部测试等价于vitest runnpm run test:watch启动监听模式先跑一遍全部测试之后监听文件变化并只重新运行发生变更的测试npm run test:watch path同上但只针对指定路径运行速查文档特别指出watch 模式much quicker as a lot of the work is cached——因为 Vitest 内置了转换缓存与模块图复用变更感知change detection让重跑范围被压缩到最小这是它比全量重跑更快的关键原因。而test:watch path则允许你把范围进一步收窄到单个文件或目录例如npm run test:watch test/utils-tests.ts除了速查文档提到的三条命令仓库还提供了几条补充脚本用于更细分的测试场景npm run test-coverage等价于vitest run --coverage基于 v8 生成文本、JSON、HTML 三种格式的覆盖率报告见 vitest.config.ts 与 package.jsonnpm run test-min以cross-env SKIP_EXPENSIVE_TESTStrue vitest run运行跳过耗时用例适合快速回归见 package.jsonnpm run test:props仅运行properties-validation-tests.ts专门校验etc/config下各语言.properties配置见 package.json。测试项目的组织结构一个配置、两个 projectVitest 采用 projects早期版本称 workspace机制将仓库测试划分为两个独立的运行单元配置集中在 vitest.config.tsunit后端单元测试include为test/**/*.ts排除test/_*.ts与test/utils.tssetupFiles注入test/_setup-fake-aws.ts与test/_setup-log.tsfrontend unit前端单元测试include为static/tests/**/*.ts排除static/tests/_*.tssetupFiles注入static/tests/_setup-dom.ts且environment指定为happy-dom。这种划分与仓库的目录约定一一对应后端逻辑lib/下的编译器、执行器、配置加载等模块的测试位于 test/前端代码static/下的组件、widget、URL 序列化等的单元测试位于 static/tests/。配套的 TypeScript 检查通过 tsconfig.tests.json 覆盖test/**/*.ts。setup 文件做了什么三个 setup 文件文件名以下划线开头因此不会被当作测试用例收集分别解决不同问题test/_setup-fake-aws.ts调用fakeCredentialsForTest()为涉及 AWS SDK 的用例注入假凭据避免测试依赖真实云环境test/_setup-log.ts调用suppressConsoleLog()在测试期间静默日志输出保持测试输出的整洁定义见 lib/logger.tsstatic/tests/_setup-dom.ts为前端用例设置__webpack_public_path__并注入一个带httpRoot、staticRoot、extraOptions属性的假#configDOM 节点模拟页面启动前的前端全局配置。从源码结构可以推断前端的 DOM 依赖被刻意控制到极简程度正如 static/tests/README.md 所写这些用例super simple只用假 document 做快速校验凡是需要真实浏览器行为pug 渲染、交互流程的场景一律交给 Cypress。官方说明见 docs/internal/FrontendTesting.md其中也明确指出happy-dom仅提供extremely minimal的 DOM 模拟。Cypress 端到端用例位于 cypress/e2e/运行方式参见 docs/UsingCypress.md。编写测试从vitest导入一切速查文档的核心建议只有一句话像用 Jest 一样使用describe、it和expect但统一从vitest导入。这一点在仓库测试中得到了严格执行例如 test/utils-tests.tsimport {describe, expect, it} from vitest;再看 test/checks.tsimport {afterAll, beforeAll, describe, expect, it} from vitest;也就是说Jest 时代的jest/globals、types/jest全局类型都不再需要测试代码里只认vitest这一个导入来源。异步断言的推荐写法速查文档给出的异步断言范式是await expect(someAsyncThing()).resolves.toEqual(someValue);与之对应的失败断言是await expect(...).rejects.toThrow(...)。推荐resolves/rejects而非直接await裸 Promise 的理由很实际当断言失败时Vitest 能保留完整的 diff 信息与异步上下文错误定位更清晰且代码风格统一、可读性好。常用匹配器速查文档专门强调expectis pretty rich举了两个例子expect(x).toContain(moo); // 数组/字符串包含断言 expect(y).not.toHaveProperty(badger); // 属性不存在断言配合 .not 反转完整的匹配器列表可在 Vitest 官方 Expect API 文档中查询。仓库测试中这些匹配器被大量使用如 test/utils-tests.ts 用expect(utils.splitLines(...)).toEqual([...])做逐场景的字符串分割断言test/checks.ts 则用expect(differences).toEqual({})校验各语言.properties中声明的库与配置文件中的libs.*.name条目完全一致属于典型的仓库自洽性config drift检查。实战示例一段完整的 Vitest 用例长什么样结合 test/utils-tests.ts一个符合 CE 规范的测试块大致如下import {describe, expect, it} from vitest; import * as utils from ../lib/utils.js; describe(Splits lines, () { it(handles empty input, () { expect(utils.splitLines()).toEqual([]); }); it(handles a single line with no newline, () { expect(utils.splitLines(A line)).toEqual([A line]); }); it(handles multiple lines, () { expect(utils.splitLines(A line\nAnother line\n)).toEqual([A line, Another line]); }); it(handles \\r\\n lines, () { expect(utils.splitLines(Some\r\nLines\r\n)).toEqual([Some, Lines]); }); });可以提炼出 CE 测试编写的几条惯例一个describe对应一个被测函数/模块一个it对应一个边界场景用例命名直接描述行为handles empty inputdescribe/it块内不做多余装饰纯断言配合 setup 文件统一处理全局副作用断言优先使用toEqual而非toBe适合比较数组、对象等结构化数据涉及环境初始化/清理时使用beforeAll/afterAll如 test/checks.ts 中先properties.initialize(...)再在收尾properties.reset()。给仓库外读者的迁移建议虽然速查文档是为 CE 内部团队写的但其模式可以直接迁移到其他从 Jest 切换到 Vitest 的 TypeScript 项目将测试中的import {...} from jest/globals全部替换为from vitestdescribe/it/expect用法保持不变利用 Vitest 的projects机制把后端纯逻辑测试与前端 DOM 相关测试分开前端部分配置environment: happy-dom或jsdom用setupFiles集中处理测试环境副作用假凭据、日志静默、全局 DOM 桩让每个用例保持只有断言的干净形态把npm test定义为vitest run、test:watch定义为vitest即可获得文档中所说的缓存加速与变更感知重跑。需要注意的前提是CE 仓库要求 Node.js22.22.1见 package.jsonVitest 版本为 4.x见 package.json若你的项目版本不同配置项如projects的写法可能需要相应调整。【免费下载链接】compiler-explorerRun compilers interactively from your web browser and interact with the assembly项目地址: https://gitcode.com/gh_mirrors/co/compiler-explorer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考