本文将深入剖析一个核心问题：为什么在 Mocha 的 `describe` 块内直接使用 `await import()` 会失效？以及，如何采用符合 ESM 规范的标准方案，实现与 CommonJS 时代同样简洁的模块化测试组织方式。核心思路是：顶层静态导入 + 函数式测试套件导出。
当项目从 CommonJS 迁移到 ECMAScript 模块（ESM）时，许多开发者不自觉地沿用旧模式——在 `describe` 块里动态 `require()` 测试文件。例如下面这种写法：
// ❌ 错误示例：ESM 中不可行describe('functional tests', async function() { await import('./function/test.spec.js'); // 不会触发其中的 it()/describe()});这个写法在 Mocha（v10+，Node ≥14.8.0，ESM 模式）下会完全失效，运行结果就是 0 passing (0ms)。问题究竟出在哪里？
首先，`import()` 是异步操作，返回一个 Promise，而 Mocha 的 `describe` 块是同步执行的，它会在代码执行时立即注册测试用例。这意味着，`await import()` 虽然加载了模块，但其内部的 `it`/`describe` 调用发生在 `describe` 块作用域之外，Mocha 在同步阶段根本识别不到它们。此外，ESM 模块的顶层代码虽然会在导入时执行，但如果没有被 Mocha 主流程同步识别（比如在顶层或 `describe` 回调中直接调用），这些测试逻辑也不会被注册。
简单来说，这是异步加载与同步注册之间的根本矛盾。
正确的解法是采用 顶层静态导入 + 函数封装测试套件，这也是 Mocha 官方推荐的 Dynamically Generating Tests 模式。具体操作分两步：
- 将每个测试文件改写为导出一个函数，函数内部调用 `it`、`describe` 等 Mocha 接口。例如：
// ./unit/test.spec.jsexport default function() { describe('Math operations', () => { it('should add correctly', () => { expect(1 + 1).toBe(2); }); });}- 在主测试入口文件中，使用顶层 `import` 并传入 `describe`：
// test/index.mjs（确保文件后缀为 .mjs 或 package.json 中 type: "module"）import unitSuite from './unit/test.spec.js';import functionalSuite from './functional/test.spec.js';describe('Unit Tests', unitSuite);describe('Functional Tests', functionalSuite);✅ 这个方案的优势非常明显：
- 完全同步、可预测，Mocha 能正确解析所有嵌套的 `it` 和 `describe`；
- 支持任意嵌套层级和组合逻辑（比如条件加载）；
- 兼容 TypeScript、Babel、Vitest 等生态工具链；
- 无需额外插件或配置。
⚠️ 有几个注意事项需要特别留意：
- 确保 Node 版本 ≥14.8.0，且测试文件以 `.mjs` 后缀命名，或在 `package.json` 中声明 `"type": "module"`；
- 不要使用 `async describe` 或 `await import()` 在测试定义块内——这违反了 Mocha 的同步注册机制；
- 如果确实需要按需加载（比如跳过某些环境下的测试），可以在顶层 `import` 前加条件判断，但 `describe` 调用本身必须同步发生。
总结一下：Mocha 的测试注册是同步过程，ESM 的 `import()` 是异步加载机制，二者在“动态块内导入”场景下本质不兼容。坚持使用 顶层静态导入 + 函数式套件导出，就能无缝迁移原有的 CommonJS 测试结构，保持清晰的分层与可靠的执行。
