Jest 迁移指南从 Jasmine、Mocha、AVA 等测试框架平滑迁移到 Jestjest-codemods 实战【免费下载链接】jestDelightful JavaScript Testing.项目地址: https://gitcode.com/gh_mirrors/je/jest导读本文面向希望把已有测试代码库迁移到 Jest 的开发者主体内容基于本仓库的 docs/MigrationGuide.md。Jest 在设计上兼容 Jasmine 及其类似 API如 Mocha并提供了以 jest-codemods 为代表的自动化迁移工具可以大幅降低从 AVA、Chai、Expect.js、Jasmine、Mocha、proxyquire、Should.js、Tape、Sinon 等框架迁移的成本。读完本文你将掌握Jest 与其他主流测试框架的兼容边界、使用 jest-codemods 完成自动化迁移的操作流程以及迁移后如何结合本仓库源码确认配置与行为差异、完成收尾验证。迁移前的兼容性评估在动手迁移之前先判断现有测试代码与 Jest 的兼容程度。根据 docs/MigrationGuide.md官方给出了三条路径正在使用 Jasmine 或 Jasmine 风格 API例如 MochaJest 与这类 API 大体兼容迁移复杂度最低通常可以直接运行测试再逐步修正差异。正在使用 AVA、Expect.jsAutomattic 版、Jasmine、Mocha、proxyquire、Should.js 或 Tape可以使用 jest-codemods 自动迁移。喜欢 chai升级到 Jest 后可以继续使用 chai 断言库但官方建议尝试 Jest 原生断言及其失败信息展示同样可以用 jest-codemods 从 chai 迁移。需要说明的是Jest 对 Mocha 的兼容并非零成本。从源码结构看Jest 自身同时保留了jest-circus与jest-jasmine2两套 runner见 packages/jest-circus 与 packages/jest-jasmine2其中jest-circus是默认 runner默认配置testRunner: jest-circus/runner定义于 packages/jest-config/src/Defaults.ts。这意味着迁移时可以通过配置testRunner切换 runner 行为常见差异如钩子执行顺序、beforeEach/afterEach的异步处理、done回调约束在切换 runner 后表现可能不同。使用 jest-codemods 自动化迁移jest-codemods 是什么jest-codemods 是一个第三方迁移工具它基于 jscodeshift 对现有测试代码执行代码转换自动完成大部分脏活。官方文档 docs/MigrationGuide.md 明确支持以下来源框架AVAChaiExpect.jsAutomatticJasmineMochaproxyquireShould.jsTapeSinon运行转换命令在包含测试代码的项目目录下执行npx jest-codemods命令运行后会以交互方式引导你选择源框架类型、要转换的测试文件范围默认匹配**/*.test.js等常见测试文件模式然后基于 jscodeshift 批量改写代码。jest-codemods 能自动改写什么结合 docs/MigrationGuide.md 与 jest-codemods 的公开能力自动转换主要覆盖以下几类改写这也是迁移到 Jest 后需要重点检查的行为差异点断言库 API 转换例如 Chai 的expect(x).to.equal(y)改写为 Jest 的expect(x).toBe(y)Should.js 的x.should.equal(y)改写为expect(x).toBe(y)Tape 的t.equal(x, y)改写为expect(x).toBe(y)等。spy/stub 与 mock 体系转换Sinon 的sinon.spy()、sinon.stub()改写为jest.spyOn()/jest.fn()proxyquire 的proxyquire(...)改写为jest.mock(...)配合require或import。测试结构 API 转换Mocha 的describe/it与 Jest 的describe/test同构转换器主要调整断言与 mock 部分before/after等钩子保持语义等价。注意jest-codemods 是第三方工具转换结果仍需人工 review。对于复杂 mock、异步断言和自定义 helper自动改写可能不完整需要手动补全。迁移到 Jest 后必读的配套文档迁移不是一蹴而就官方在 docs 目录中提供了与迁移直接相关的系列文档建议按以下顺序阅读文档解决什么问题docs/GettingStarted.md安装、最小测试用例、CLI 运行方式、Babel/TypeScript 配置docs/Configuration.md全部配置项说明迁移时逐项核对你的 jest 配置docs/CLI.md命令行参数迁移后如何运行测试与调试docs/MockFunctionAPI.mdmock 函数、spy 的完整 API含jest.Spied类型docs/JestObjectAPI.mdjest对象上的全部方法含createMockFromModuledocs/UpgradingToJest29.md从 v28 迁移到 v29 的破坏性变更docs/UpgradingToJest30.md从 v29 迁移到 v30 的破坏性变更其中 docs/UpgradingToJest30.md 对迁移者尤其重要它记录了 Jest 30 对旧 API 的清理例如全部别名匹配器已移除toBeCalled()→toHaveBeenCalled()、toReturn()→toHaveReturned()、toThrowError()→toThrow()等jest.genMockFromModule()已移除统一改用jest.createMockFromModule()jest.SpyInstance类型已移除改用jest.Spied详见 docs/JestObjectAPI.md 与 docs/MockFunctionAPI.md--testPathPattern更名为--testPathPatternsjest --init命令被移除改为npm init jestlatest。迁移后的配置核对清单迁移后建议对照默认配置逐项核对。当前仓库的默认配置集中在 packages/jest-config/src/Defaults.ts其中与迁移最相关的默认值如下配置项默认值迁移注意点testEnvironmentjest-environment-node原前端 DOM 测试如 Mocha jsdom需显式配置为jest-environment-jsdom否则document/window不可用testMatch[**/__tests__/**/*.?([mc])[jt]s?(x), **/?(*.)(spec|test).?([mc])[jt]s?(x)]若旧测试文件命名不符合该模式如*_test.js、*.tests.js需自定义testMatch或testRegex两者不能同时使用见 docs/Configuration.mdmoduleFileExtensions[js, mjs, cjs, jsx, ts, mts, cts, tsx, json, node]覆盖 CommonJS 与 ESM、TS 全部常用扩展名一般无需修改clearMocks/resetMocks/restoreMocks均为false若旧框架在测试间自动重置 spy建议开启restoreMocks详见 docs/Configuration.md避免测试串扰testRunnerjest-circus/runner需要 Jasmine 2 行为时可显式切回jest-jasmine2coverageProviderbabel与旧框架的覆盖率工具如 istanbul 直用集成方式不同按需调整为v8testPathIgnorePatternsnode_modules 等确认迁移后的 fixture 目录不会被误识别为测试迁移示例node 环境与 jsdom 环境原 Mocha 测试通常依赖全局describe/it且可能直接使用 Node 全局对象。迁移到 Jest 后最简单的package.json配置如下{ scripts: { test: jest }, jest: { testEnvironment: node } }对于原本运行在浏览器环境DOM中的测试例如使用 jsdom 的 Mocha 测试迁移后必须切换环境{ jest: { testEnvironment: jsdom } }本仓库中 e2e/custom-jsdom-version、e2e/test-environment 等 e2e 用例展示了不同testEnvironment的实测行为可作参考。迁移示例自定义 testMatch 兼容旧命名如果旧测试文件叫math_test.js下划线风格Jest 默认不会识别需要在配置中显式声明{ jest: { testMatch: [ **/__tests__/**/*.js, **/?(*.)(spec|test).js, **/*_test.js ] } }注意testMatch与testRegex互斥只能二选一见 docs/Configuration.md 与 docs/Configuration.md。迁移后代码层面需要检查的三类差异1. 断言与匹配器 API若继续使用 chai可以直接import chai from chai并在测试中调用Jest 不禁止第三方断言库若切换到 Jest 断言注意使用规范名称避免 Jest 30 已移除的别名toBeCalled、toReturn、toThrowError等涉及异步断言时优先使用expect(promise).resolves/rejects语法这是 Jest 原生能力相关用法参见 docs/ExpectAPI.md。2. mock 与 spy 体系proxyquire 的使用方式需要改为jest.mock()先jest.mock(./dep)再在测试中require(./dep)拿到 mock 实例断言调用Sinon 的sinon.spy(obj, method)对应jest.spyOn(obj, method)返回值可以用jest.Spiedtypeof obj.method注解见 docs/MockFunctionAPI.md需要手动 mock 继承自动 mock的场景使用jest.createMockFromModule()。官方在 docs/JestObjectAPI.md 给出完整示例createMockFromModule对函数生成 mock function、对类生成全部成员被 mock 的类、对对象生成深克隆、对数组生成空数组、对原始类型保持同值。典型用法const utils jest.createMockFromModule(../utils); utils.isAuthorized jest.fn(secret secret not wizard); test(implementation created by jest.createMockFromModule, () { expect(jest.isMockFunction(utils.authorize)).toBe(true); expect(utils.isAuthorized(not wizard)).toBe(true); });3. 测试环境与全局对象旧测试若依赖global上挂载的变量如global.__DEV__迁移后可通过 docs/Configuration.md 中的globals配置注入依赖process.env的环境变量测试可结合 setupFiles 在测试启动前统一设置见 docs/Configuration.md需要在每个测试文件运行前扩展匹配器或挂载全局工具的使用setupFilesAfterEnv见 docs/Configuration.md。迁移后的验证流程迁移完成后的建议验证步骤先跑起来在项目根目录执行npm test或yarn test观察测试发现test discovery是否完整——重点关注被漏掉的测试文件多为命名模式不匹配导致。核对环境报错若出现document is not defined之类错误说明testEnvironment需要切换为jsdom若出现 ES 模块语法报错检查是否配置 Babelbabel-jestbabel/preset-env参见 docs/GettingStarted.md或extensionsToTreatAsEsm。逐个修复失败用例优先修复 mock 相关失败proxyquire → jest.mock 的改写通常需要人工确认再处理断言差异。检查 TypeScript 报错若使用jest/globals显式导入类型注意 Jest 30 已移除MockFunctionMetadata、SpyInstance等类型改用jest.Spied见 docs/UpgradingToJest30.md。运行覆盖率对比迁移后执行jest --coverage与旧框架覆盖率报告对比确认没有被跳过或漏测的模块。本仓库自带完整的 e2e 测试套件见 e2e/tests覆盖了配置解析、mock 行为、快照、并发、watch 模式等大量真实场景如果你在迁移中遇到具体行为不确定可以直接在 e2e 目录中检索对应的 e2e 用例来验证 Jest 的预期行为。结语从 Jasmine、Mocha、AVA、Chai 等框架迁移到 Jest核心路径是先评估兼容性再用 jest-codemods 自动改写大部分机械转换最后对照 docs/Configuration.md 逐项核对配置、手动修复 mock 与异步断言等差异。官方文档 docs/MigrationGuide.md 提供的是迁移起点而当前仓库的源码packages/jest-config、packages/jest-circus、升级指南docs/UpgradingToJest29.md、docs/UpgradingToJest30.md与 e2e 测试用例则是迁移过程中最可靠的行为参照。【免费下载链接】jestDelightful JavaScript Testing.项目地址: https://gitcode.com/gh_mirrors/je/jest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jest 迁移指南：从 Jasmine、Mocha、AVA 等测试框架平滑迁移到 Jest（jest-codemods 实战）
Jest 迁移指南从 Jasmine、Mocha、AVA 等测试框架平滑迁移到 Jestjest-codemods 实战【免费下载链接】jestDelightful JavaScript Testing.项目地址: https://gitcode.com/gh_mirrors/je/jest导读本文面向希望把已有测试代码库迁移到 Jest 的开发者主体内容基于本仓库的 docs/MigrationGuide.md。Jest 在设计上兼容 Jasmine 及其类似 API如 Mocha并提供了以 jest-codemods 为代表的自动化迁移工具可以大幅降低从 AVA、Chai、Expect.js、Jasmine、Mocha、proxyquire、Should.js、Tape、Sinon 等框架迁移的成本。读完本文你将掌握Jest 与其他主流测试框架的兼容边界、使用 jest-codemods 完成自动化迁移的操作流程以及迁移后如何结合本仓库源码确认配置与行为差异、完成收尾验证。迁移前的兼容性评估在动手迁移之前先判断现有测试代码与 Jest 的兼容程度。根据 docs/MigrationGuide.md官方给出了三条路径正在使用 Jasmine 或 Jasmine 风格 API例如 MochaJest 与这类 API 大体兼容迁移复杂度最低通常可以直接运行测试再逐步修正差异。正在使用 AVA、Expect.jsAutomattic 版、Jasmine、Mocha、proxyquire、Should.js 或 Tape可以使用 jest-codemods 自动迁移。喜欢 chai升级到 Jest 后可以继续使用 chai 断言库但官方建议尝试 Jest 原生断言及其失败信息展示同样可以用 jest-codemods 从 chai 迁移。需要说明的是Jest 对 Mocha 的兼容并非零成本。从源码结构看Jest 自身同时保留了jest-circus与jest-jasmine2两套 runner见 packages/jest-circus 与 packages/jest-jasmine2其中jest-circus是默认 runner默认配置testRunner: jest-circus/runner定义于 packages/jest-config/src/Defaults.ts。这意味着迁移时可以通过配置testRunner切换 runner 行为常见差异如钩子执行顺序、beforeEach/afterEach的异步处理、done回调约束在切换 runner 后表现可能不同。使用 jest-codemods 自动化迁移jest-codemods 是什么jest-codemods 是一个第三方迁移工具它基于 jscodeshift 对现有测试代码执行代码转换自动完成大部分脏活。官方文档 docs/MigrationGuide.md 明确支持以下来源框架AVAChaiExpect.jsAutomatticJasmineMochaproxyquireShould.jsTapeSinon运行转换命令在包含测试代码的项目目录下执行npx jest-codemods命令运行后会以交互方式引导你选择源框架类型、要转换的测试文件范围默认匹配**/*.test.js等常见测试文件模式然后基于 jscodeshift 批量改写代码。jest-codemods 能自动改写什么结合 docs/MigrationGuide.md 与 jest-codemods 的公开能力自动转换主要覆盖以下几类改写这也是迁移到 Jest 后需要重点检查的行为差异点断言库 API 转换例如 Chai 的expect(x).to.equal(y)改写为 Jest 的expect(x).toBe(y)Should.js 的x.should.equal(y)改写为expect(x).toBe(y)Tape 的t.equal(x, y)改写为expect(x).toBe(y)等。spy/stub 与 mock 体系转换Sinon 的sinon.spy()、sinon.stub()改写为jest.spyOn()/jest.fn()proxyquire 的proxyquire(...)改写为jest.mock(...)配合require或import。测试结构 API 转换Mocha 的describe/it与 Jest 的describe/test同构转换器主要调整断言与 mock 部分before/after等钩子保持语义等价。注意jest-codemods 是第三方工具转换结果仍需人工 review。对于复杂 mock、异步断言和自定义 helper自动改写可能不完整需要手动补全。迁移到 Jest 后必读的配套文档迁移不是一蹴而就官方在 docs 目录中提供了与迁移直接相关的系列文档建议按以下顺序阅读文档解决什么问题docs/GettingStarted.md安装、最小测试用例、CLI 运行方式、Babel/TypeScript 配置docs/Configuration.md全部配置项说明迁移时逐项核对你的 jest 配置docs/CLI.md命令行参数迁移后如何运行测试与调试docs/MockFunctionAPI.mdmock 函数、spy 的完整 API含jest.Spied类型docs/JestObjectAPI.mdjest对象上的全部方法含createMockFromModuledocs/UpgradingToJest29.md从 v28 迁移到 v29 的破坏性变更docs/UpgradingToJest30.md从 v29 迁移到 v30 的破坏性变更其中 docs/UpgradingToJest30.md 对迁移者尤其重要它记录了 Jest 30 对旧 API 的清理例如全部别名匹配器已移除toBeCalled()→toHaveBeenCalled()、toReturn()→toHaveReturned()、toThrowError()→toThrow()等jest.genMockFromModule()已移除统一改用jest.createMockFromModule()jest.SpyInstance类型已移除改用jest.Spied详见 docs/JestObjectAPI.md 与 docs/MockFunctionAPI.md--testPathPattern更名为--testPathPatternsjest --init命令被移除改为npm init jestlatest。迁移后的配置核对清单迁移后建议对照默认配置逐项核对。当前仓库的默认配置集中在 packages/jest-config/src/Defaults.ts其中与迁移最相关的默认值如下配置项默认值迁移注意点testEnvironmentjest-environment-node原前端 DOM 测试如 Mocha jsdom需显式配置为jest-environment-jsdom否则document/window不可用testMatch[**/__tests__/**/*.?([mc])[jt]s?(x), **/?(*.)(spec|test).?([mc])[jt]s?(x)]若旧测试文件命名不符合该模式如*_test.js、*.tests.js需自定义testMatch或testRegex两者不能同时使用见 docs/Configuration.mdmoduleFileExtensions[js, mjs, cjs, jsx, ts, mts, cts, tsx, json, node]覆盖 CommonJS 与 ESM、TS 全部常用扩展名一般无需修改clearMocks/resetMocks/restoreMocks均为false若旧框架在测试间自动重置 spy建议开启restoreMocks详见 docs/Configuration.md避免测试串扰testRunnerjest-circus/runner需要 Jasmine 2 行为时可显式切回jest-jasmine2coverageProviderbabel与旧框架的覆盖率工具如 istanbul 直用集成方式不同按需调整为v8testPathIgnorePatternsnode_modules 等确认迁移后的 fixture 目录不会被误识别为测试迁移示例node 环境与 jsdom 环境原 Mocha 测试通常依赖全局describe/it且可能直接使用 Node 全局对象。迁移到 Jest 后最简单的package.json配置如下{ scripts: { test: jest }, jest: { testEnvironment: node } }对于原本运行在浏览器环境DOM中的测试例如使用 jsdom 的 Mocha 测试迁移后必须切换环境{ jest: { testEnvironment: jsdom } }本仓库中 e2e/custom-jsdom-version、e2e/test-environment 等 e2e 用例展示了不同testEnvironment的实测行为可作参考。迁移示例自定义 testMatch 兼容旧命名如果旧测试文件叫math_test.js下划线风格Jest 默认不会识别需要在配置中显式声明{ jest: { testMatch: [ **/__tests__/**/*.js, **/?(*.)(spec|test).js, **/*_test.js ] } }注意testMatch与testRegex互斥只能二选一见 docs/Configuration.md 与 docs/Configuration.md。迁移后代码层面需要检查的三类差异1. 断言与匹配器 API若继续使用 chai可以直接import chai from chai并在测试中调用Jest 不禁止第三方断言库若切换到 Jest 断言注意使用规范名称避免 Jest 30 已移除的别名toBeCalled、toReturn、toThrowError等涉及异步断言时优先使用expect(promise).resolves/rejects语法这是 Jest 原生能力相关用法参见 docs/ExpectAPI.md。2. mock 与 spy 体系proxyquire 的使用方式需要改为jest.mock()先jest.mock(./dep)再在测试中require(./dep)拿到 mock 实例断言调用Sinon 的sinon.spy(obj, method)对应jest.spyOn(obj, method)返回值可以用jest.Spiedtypeof obj.method注解见 docs/MockFunctionAPI.md需要手动 mock 继承自动 mock的场景使用jest.createMockFromModule()。官方在 docs/JestObjectAPI.md 给出完整示例createMockFromModule对函数生成 mock function、对类生成全部成员被 mock 的类、对对象生成深克隆、对数组生成空数组、对原始类型保持同值。典型用法const utils jest.createMockFromModule(../utils); utils.isAuthorized jest.fn(secret secret not wizard); test(implementation created by jest.createMockFromModule, () { expect(jest.isMockFunction(utils.authorize)).toBe(true); expect(utils.isAuthorized(not wizard)).toBe(true); });3. 测试环境与全局对象旧测试若依赖global上挂载的变量如global.__DEV__迁移后可通过 docs/Configuration.md 中的globals配置注入依赖process.env的环境变量测试可结合 setupFiles 在测试启动前统一设置见 docs/Configuration.md需要在每个测试文件运行前扩展匹配器或挂载全局工具的使用setupFilesAfterEnv见 docs/Configuration.md。迁移后的验证流程迁移完成后的建议验证步骤先跑起来在项目根目录执行npm test或yarn test观察测试发现test discovery是否完整——重点关注被漏掉的测试文件多为命名模式不匹配导致。核对环境报错若出现document is not defined之类错误说明testEnvironment需要切换为jsdom若出现 ES 模块语法报错检查是否配置 Babelbabel-jestbabel/preset-env参见 docs/GettingStarted.md或extensionsToTreatAsEsm。逐个修复失败用例优先修复 mock 相关失败proxyquire → jest.mock 的改写通常需要人工确认再处理断言差异。检查 TypeScript 报错若使用jest/globals显式导入类型注意 Jest 30 已移除MockFunctionMetadata、SpyInstance等类型改用jest.Spied见 docs/UpgradingToJest30.md。运行覆盖率对比迁移后执行jest --coverage与旧框架覆盖率报告对比确认没有被跳过或漏测的模块。本仓库自带完整的 e2e 测试套件见 e2e/tests覆盖了配置解析、mock 行为、快照、并发、watch 模式等大量真实场景如果你在迁移中遇到具体行为不确定可以直接在 e2e 目录中检索对应的 e2e 用例来验证 Jest 的预期行为。结语从 Jasmine、Mocha、AVA、Chai 等框架迁移到 Jest核心路径是先评估兼容性再用 jest-codemods 自动改写大部分机械转换最后对照 docs/Configuration.md 逐项核对配置、手动修复 mock 与异步断言等差异。官方文档 docs/MigrationGuide.md 提供的是迁移起点而当前仓库的源码packages/jest-config、packages/jest-circus、升级指南docs/UpgradingToJest29.md、docs/UpgradingToJest30.md与 e2e 测试用例则是迁移过程中最可靠的行为参照。【免费下载链接】jestDelightful JavaScript Testing.项目地址: https://gitcode.com/gh_mirrors/je/jest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
