开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载导读本文以 Positron 仓库的 .claude/rules/core-tests.md 规则文档为主体系统讲解 Positron基于 VS Code 的下一代数据科学 IDE中Core Tests核心 Mocha 测试的完整脉络它是什么、通过哪个脚本运行、位于仓库哪些位置、编写时遵循哪些约定suite()/test()/assert/ 泄漏检测以及为什么 Positron 新代码一律禁止再新建.test.ts文件而要改用 Vitest。读完本文你将掌握 Core Mocha 测试的运行命令、文件组织、代码书写范式与迁移判定依据并能据此判断手头的测试该写成.test.ts还是.vitest.ts。一、什么是 Core Tests上游 VS Code 遗留的 Mocha 测试套件在 Positron 的测试体系中Core Tests 特指src/目录下以.test.ts/.integrationTest.ts结尾、通过 Mocha 运行的遗留测试它们直接继承自上游 VS Code 的单元测试套件。规则原文的定位是Legacy Mocha tests insrc/, run via./scripts/test.sh. Used by upstream VS Code tests.这句话包含三个关键事实它们是遗留Legacy的不是 Positron 新写的测试而是 fork VS Code 时继承下来的历史资产运行入口是./scripts/test.shnpm 侧对应npm run test:core见 package.json服务对象是上游 VS Code 测试你在src/下看到的大量.test.ts文件绝大多数是 upstream 代码自带的测试。从仓库统计看当前src/下共有1708 个.test.ts文件和 50 个.integrationTest.ts文件规模庞大因此它们仍然需要被持续维护、随上游同步更新而不是一次性删除。1.1 Core Tests 在整体测试体系中的位置Positron 的测试分三层详见 CLAUDE.md 的 Testing 一节测试类别运行器典型位置文件后缀Positron Vitest新代码首选Vitestsrc/vs/**.vitest.ts/.vitest.tsxCore Mocha本文主题MochaElectron/Node/Browsersrc/vs/**/test/.test.ts/.integrationTest.tsExtension host 测试Mocha扩展宿主extensions/name/.test.tsE2E 测试Playwrighttest/e2e/.test.ts三者的区分要点Core Mocha 运行在 Electron/Node 环境、需要构建守护进程、速度较慢Vitest 直接跑在源码上、无需构建、毫秒级完成。CLAUDE.md 的决策表给出了明确的写入规则——Existing upstream VS Code test (rare) 一行才属于 Core Mocha即匹配现有约定Mocha suite()/test()而 Positron 自己的纯函数、DI 服务、React 组件测试一律走 Vitest。二、运行 Core Tests脚本入口与常用参数2.1 入口脚本scripts/test.sh规则文档指定的运行方式是./scripts/test.sh。查看 scripts/test.sh 源码可以看到它的完整流程解析仓库根目录ROOTmacOS 与 Linux 分支不同从 product.json 读取应用名定位编译产物.build/electron/name下的可执行文件若node_modules不存在则先执行npm i除非设置VSCODE_SKIP_PRELAUNCH否则执行npm run electron拉取 Electron最终用 Electron 运行测试入口test/unit/electron/index.js并传入--crash-reporter-directory$VSCODECRASHDIR崩溃日志目录默认为.build/crashes。Linux 下会额外附加--no-sandbox参数macOS 下会先ulimit -n 4096提升文件描述符上限。npm 脚本别名是npm run test:core见 package.json。前置条件重要由于scripts/test.sh最终是用编译后的 Electron 二进制去跑测试因此运行前必须保证构建守护进程已启动并完成编译。正确顺序是npm run build-start npm run build-check然后再执行npm run test:core或./scripts/test.sh。2.2 单文件与 glob 过滤scripts/test.sh会把所有剩余参数原样透传给测试入口test/unit/electron/index.js。该入口基于 minimist 解析参数见 test/unit/electron/index.js常用的过滤参数有参数别名作用--run file--只运行指定测试文件对应 CLAUDE.md 中的./scripts/test.sh --run src/path/to/file.test.ts--runGlob glob--glob/--runGrep按 glob 模式匹配多个文件注意glob 需使用.js后缀测试编译产物如./scripts/test.sh --runGlob glob.test.js--excludeRunGlob glob--在--runGlob基础上排除匹配的文件--grep pattern--g/--f按测试名称suite/test 标题过滤类似 Mocha 的--grep--timeout ms--覆盖测试超时--reporter/--reporter-options--指定 Mocha 报告器默认含 junit 报告器mocha-junit-reporter例如只跑 ActionBar 相关测试./scripts/test.sh --runGlob **/actionbar.test.js或用名称过滤./scripts/test.sh --run src/vs/base/test/browser/actionbar.test.ts --grep prepareActions2.3 运行环境Electron 内的 MochaCore Tests 并不在纯 Node 中运行而是由 Electron 主进程加载 test/unit/electron/index.js 驱动 Mocharequire(mocha)因此浏览器类测试如依赖document、BrowserWindow的用例可以在真实 Electron 环境中执行。入口文件中还设置了process.env.MOCHA_COLORS 1必须在任何 mocha import 之前并支持--dev打开开发者工具、--coverage覆盖率配合--coveragePath/--coverageFormats/--per-test-coverage等高级选项。三、Core Mocha 测试的代码约定suite()/test()/assert规则文档明确要求如果你在修改一个已有的 Mocha 测试必须匹配它的既有约定即suite()声明测试套件test()声明单个用例assert做断言来自 Node 内置node:assertensureNoDisposablesAreLeakedInTestSuite()做一次性资源泄漏检测来自utils.js。3.1 一个真实示例Actionbar 测试以 src/vs/base/test/browser/actionbar.test.ts 为例其骨架完整呈现了上述四要素import assert from assert; import { ActionBar, prepareActions } from ../../browser/ui/actionbar/actionbar.js; import { Action, Separator } from ../../common/actions.js; import { ensureNoDisposablesAreLeakedInTestSuite } from ../common/utils.js; suite(Actionbar, () { const store ensureNoDisposablesAreLeakedInTestSuite(); test(prepareActions(), function () { const a1 new Separator(); const a3 store.add(new Action(a3)); // ... const actions prepareActions([a1, a2, a3, a4, a5, a6, a7]); assert.strictEqual(actions.length, 3); // duplicate separators get removed assert(actions[0] a3); }); });几个值得注意的细节测试文件与被测代码同目录层级actionbar.test.ts位于src/vs/base/test/browser/对应被测的src/vs/base/browser/ui/actionbar/actionbar.js。Mocha 测试统一放在src/vs/**/test/目录下test/与源码目录一一对应。import 使用.js后缀尽管仓库源码是 TypeScript但遵循 VS Code 的 ESM 转换约定模块引用统一写.js如../../browser/ui/actionbar/actionbar.js。断言使用assert既有 Mocha 测试用 Node 断言风格assert.strictEqual、assert(...)这与 Vitest 的expect(...).to*(...)风格截然不同详见下文迁移章节。3.2ensureNoDisposablesAreLeakedInTestSuite()的底层原理规则文档点名要求每个 suite 使用该工具。它定义在 src/vs/base/test/common/utils.ts实现逻辑是setup()阶段创建DisposableStore和DisposableTracker并通过setDisposableTracker(tracker)注册全局跟踪器——此后测试中创建的所有IDisposable都会被记录teardown()阶段先store.dispose()释放测试自己登记的资源再setDisposableTracker(null)取消跟踪只有当当前测试未失败时this.currentTest?.state ! failed才调用tracker.computeLeakingDisposables()检查泄漏若存在泄漏则console.error明细并抛出There are N undisposed disposables!使测试失败返回值是一个包装了内部store的{ addT extends IDisposable(o: T): T }对象测试中可像示例那样用store.add(new Action(a3))登记资源teardown 时会自动释放。这套机制保证了每个用例结束后不会残留未释放的事件监听、订阅或 DOM 引用是 Core Mocha 测试零泄漏的守门员。类似的工具还有throwIfDisposablesAreLeaked()/throwIfDisposablesAreLeakedAsync()同步/异步的一次性泄漏检查以及suiteRepeat/testRepeat重复执行 suite/test用于排查偶发问题和assertThrowsAsync异步异常断言它们都集中在同一个 utils.ts 中。四、迁移决策为什么 Positron 新代码禁止新建.test.ts规则文档最核心的一条约束是Do not create new.test.tsfiles for Positron code.Use Vitest (.vitest.ts/.vitest.tsx) instead -- see the decision table in CLAUDE.md and.claude/rules/vitest-tests.mdfor patterns.4.1 原因Core Mocha 的三重劣势需要构建守护进程scripts/test.sh必须用编译后的 Electron 产物运行改动源码后要等编译周期反馈慢运行慢整套 Mocha 套件体量庞大1700 文件全量跑一次耗时很长不适合作为新代码的日常测试反馈环与上游同步成本高src/下绝大多数.test.ts属于 upstream VS CodePositron 若在其中新增文件会加大 fork 合并冲突的风险CLAUDE.md 的 Upstream Compatibility 一节明确要求尽量新文件、避免修改上游文件。4.2 替代方案Vitest 三种模式对应的 .claude/rules/vitest-tests.md 给出了替代范式全部直接运行在源码上npx vitest run file单次运行、npx vitest --watch file监听模式被测对象模式示例纯函数、无服务的类Plain testpositronUpdateUtils.vitest.ts需要 DI 服务的类BuildercreateTestContainer().withX().stub().build()src/vs/test/vitest/positronTestContainer.tsReact 组件RTLsetupRTLRenderer()/withReactServices()webviewPlotThumbnail.vitest.tsx、startupStatus.vitest.tsx4.3 例外情况什么情况下仍会接触 Core Mocha规则文档没有把 Core Mocha 一票否决而是划定了明确边界修改既有 Mocha 测试时上游同步、修 bug 导致断言变化必须按原文件约定继续使用suite()/test()/assert不要混入 Vitest 语法涉及上游 VS Code 文件时你在src/vs/**触碰 upstream 代码其配套测试自然是.test.ts需要随改动更新。也就是说不新建针对的是 Positron 自有代码上游测试的维护仍是日常开发的一部分。CLAUDE.md 的决策表将该场景标为 Existing upstream VS Code test (rare)——频率低但遇到时要有正确的维护姿势。4.4 实用判别口诀写测试前先问自己三个问题这段代码是 Positron 新增的还是 upstream 已有的——Positron 新增一律 Vitest被测逻辑能否脱离vscodeAPI 和构建产物独立运行——能则 Vitestextensions/下不 importvscode的纯模块也可用.vitest.ts我是在修一个已存在的.test.ts吗——是则跟随既有 Mocha 约定。五、常见陷阱与维护要点5.1 不要混用断言风格Vitest 明确要求expect(x).to*(...)neverassert.ok/assert.equal/assert.strictEqual见 vitest-tests.md。反过来修改 Core Mocha 文件时也不要引入expect。两种断言体系在各自的套件中并行存在靠文件后缀.test.tsvs.vitest.ts区分。5.2 泄漏检测不可省略任何一个新建或大改的 Core Mocha suite 都应调用ensureNoDisposablesAreLeakedInTestSuite()否则资源泄漏事件监听、订阅、DOM 节点会静默累积导致后续用例出现难排查的偶发失败。该工具在 src/vs/base/test/common/utils.ts 中通过全局DisposableTracker实现值得留意的是它只在用例通过时检查泄漏——失败的用例不再额外抛泄漏错误避免掩盖真正的失败原因。5.3 运行前的构建依赖npm run test:core依赖编译产物忘记启动构建守护进程会得到陈旧的二进制甚至运行失败。规范的流程是npm run build-start # 后台启动构建守护进程 npm run build-check # 等待当前编译周期结束并查看错误 npm run test:core # 运行全部 Core Mocha 测试 ./scripts/test.sh --run src/vs/path/to/file.test.ts # 或精确到单个文件六、结语Core Tests 是 Positron 从 VS Code fork 中继承的 Mocha 测试资产1700 多个.test.ts/.integrationTest.ts文件构成了核心源码的行为基线通过./scripts/test.sh即npm run test:core在 Electron 中运行。理解它的运行入口scripts/test.sh、参数体系test/unit/electron/index.js、书写约定suite()/test()/assertensureNoDisposablesAreLeakedInTestSuite()见 utils.ts与迁移边界既是维护上游兼容性的基本功也是为 Positron 新代码选对测试框架Vitest的前提。规则文档的一句话总结是最好的收尾不要在 Positron 代码中新建.test.ts但遇到上游 Mocha 测试时请严格遵守它的既有约定。赞分享开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载相关推荐AssetRipper 深度解析Unity 游戏资产逆向工程一步到位AssetRipper 深度解析Unity 游戏资产逆向工程一步到位 AssetRipper 是目前少数能跑通完整 Unity 资产逆向工程链路的开源工具从开发工具逆向工程游戏开发vitest迁移指南从Jest到vitest的无痛转换vitest迁移指南从Jest到vitest的无痛转换 痛点为什么需要迁移 还在为Jest的缓慢测试速度烦恼吗还在为复杂的配置和缓慢的watch模式感到测试前端开发工具深入解析 elsa-core 的 EF Core 迁移脚本体系从运行时 Schema 到多 Provider 迁移生成深入解析 elsa core 的 EF Core 迁移脚本体系从运行时 Schema 到多 Provider 迁移生成 导读 本文围绕 scripts/mig后端工作流自动化流程编排低代码上一篇Gemini CLI github-issue-creator 技能基于模板驱动与 gh CLI 的 GitHub Issue 自动化创建流程下一篇如何贡献Remote项目新手也能轻松上手的开源协作指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考