atom本身不运行测试，仅调用项目中已配置的测试命令（如ava、jest）；插件只触发执行并解析输出，不管理进程生命周期，需手动清理全局状态与mock。

Atom 本身不运行测试，它只是调用你配好的命令

Atom 没有内置测试引擎，cmd+shift+t 或 ctrl+shift+t 按下后实际执行的，是你项目里已安装的测试框架（如 jest、ava、unittest）的 CLI 命令。插件只做“触发”和“解析输出”，不接管执行过程。

这意味着：如果你没在项目中装 ava，装了 atom-ava 插件也跑不起来；如果你的 package.json 里没定义 "test" 脚本，atom-build 配了 cmd: npm test 也会报错“command not found”。

• 所有插件都不管理测试进程生命周期——测试卡住、残留子进程、全局 mock 未清理，都得你自己处理
• 错误堆栈默认不带源码映射，TypeScript 或 Babel 编译后报错定位到 .js 文件，不是你写的 .ts 或 .jsx
• Atom 当前打开的“项目根目录”决定 cwd，不是文件所在路径——这点在多包（Lerna）、monorepo 或嵌套子目录中极易出错

用 atom-ava 跑 AVA 测试：轻量但限制明确

适合小型 JS/TS 项目或快速验证逻辑，不依赖复杂配置，但对文件结构和环境要求很具体。

• 必须在项目根目录执行 npx ava --init，生成 package.json 中的 ava 字段，否则插件静默失败
• 只识别 .test.js、.spec.js、.test.ts 后缀的文件；index.test.js 可以，utils_test.js 不行
• 快捷键只对当前打开的测试文件或其父目录生效——如果当前是 src/index.js，不会自动找同名 src/index.test.js
• 若用了 TypeScript，需在 package.json 的 ava 字段中显式加 "sourceMaps": true，否则断点和堆栈指向编译后代码

用 Nuclide（Jest）跑大型前端项目：功能强但已停更

Nuclide 是目前 Atom 中对 React / TypeScript / Lerna 多包项目支持最完整的方案，但它自 2021 年起已停止维护，使用前需确认兼容性。

• 测试文件必须放在 __tests__/ 目录下，例如 modules/nuclide-commons/__tests__/someModule-test.js；src/*.test.tsx 不会被识别
• 必须存在有效的 jest.config.js，且若用 ts-jest，还需确保 jest.setup.js 正确加载了编译环境
• 启动前必须执行 apm link --dev + atom --dev，否则测试面板根本不加载
• 运行时 cwd 是 Atom 打开的最外层项目根目录，不是单个包路径——比如你在 packages/foo 里打开文件，但 Atom 根是 monorepo/，那 Jest 就从 monorepo/ 启动，可能找不到 packages/foo/jest.config.js

用 atom-build 自定义任意测试命令：最灵活也最容易踩坑

当你需要跑 vitest、cypress、pytest 或自定义 mocha 脚本时，atom-build 是唯一可控的选择，但配置细节决定成败。

• 必须在项目根目录建 atom-build.yml，不能只写 cmd: npm test；Windows 下要加 sh: true，否则报 'npm' is not recognized
• cwd 必须设为 "."（项目根），否则 node_modules/.bin 下的二进制找不到
• 错误匹配靠 errorMatch 正则提取堆栈行，比如 Python 的 File ".*", line \d+，漏配就点不了错误跳转
• 不支持并发测试重载——改完代码再按一次快捷键，上一个测试进程可能还在跑，导致端口占用或状态污染

真正麻烦的从来不是“怎么让测试跑起来”，而是“怎么让失败的测试准确报错、快速定位、不污染下次运行”。插件只负责管道，管道两端——测试框架本身的健壮性、项目配置的收敛性、以及你是否手动清理了 jest.clearAllMocks() 或 sinon.restore()——才是实际卡住人的地方。