图形学游戏开发3D渲染【免费下载链接】Babylon.jsBabylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.项目地址https://gitcode.com/gh_mirrors/ba/Babylon.js点击查看免费下载Babylon.js 的核心渲染引擎源码以dev/core工作区包的形式存放于 packages/dev/core其 readme.md 用最简篇幅给出了两条测试命令运行完整测试套件npm test与仅运行单个测试文件npm run test -w dev/core -- -i file。本文以这两条命令为骨架结合仓库根目录与包级的package.json脚本、vitest.config.mts 的项目配置以及 packages/dev/core/test/unit/Physics 下的真实测试用例讲解如何在 monorepo 中跑通、缩小并理解dev/core的单元测试帮助开发者高效验证对引擎源码的改动。dev/core 是什么测试对象与适用前提dev/core是 Babylon.js monorepo 中面向开发阶段的 TypeScript 源码包包含了引擎Engine/NullEngine、场景Scene、网格Meshes、材质Materials、相机Cameras、物理Physics、粒子、动画等核心模块的实现源码位于 packages/dev/core/src。其包清单定义在 packages/dev/core/package.jsonmain/module/types均指向dist/index属于private: true的工作区内部包不直接对外发布。使用本文命令前需满足仓库根 package.jsonengines字段声明的环境node ^20.19.0 || 22.13.0 23.0.0 || 24.0.0 25.0.0npm 11.18.0。仓库通过根 package.json 的workspaces: [packages/**/*]与 lerna.json 的packages: [packages/**/*]管理多包依赖因此npm run test -w dev/core这种 workspace 语法可以精确锁定目标包。快速开始运行dev/core完整测试套件原文档给出的第一条命令是npm test在仓库根目录执行时它等价于根 package.json 中test: vitest run --projectunit即只运行unit测试项目。而在 packages/dev/core/package.json 内部dev/core自己的测试脚本是test: vitest run。两种方式的差异在于npm test根按 vitest.config.mts 中projects配置的unit项目统一调度理论上会扫描所有包的单元测试npm run test -w dev/core包级把 vitest 的启动目录限定在dev/core只收集该包范围内的用例迭代单个包时更聚焦。dev/core的单元测试集中存放在 packages/dev/core/test/unit按引擎模块分目录组织例如Animations/、Cameras/、Meshes/、Physics/、Particles/、Scene/等顶层还有babylon.assetContainer.test.ts、babylon.node.test.ts、babylon.scene.materials.test.ts等场景级用例。单文件测试文档命令的逐段拆解原文档给出的第二条命令是npm run test -w dev/core -- -i test/Physics/babylon.physicsComponents.test.ts把它拆开来看各段含义如下npm run test -w dev/core运行dev/core包内的test脚本即vitest run--npm 的分隔符其后所有参数原样透传给vitest-i globvitest 的--include过滤选项指示本次运行只收集匹配该模式或路径片段的测试文件。其中-i后跟的路径是相对于包根目录的。需要特别提醒原文档写作时的测试路径布局与当前仓库略有出入。当前仓库中dev/core的测试统一放在test/unit/之下而不是test/且原文档提到的babylon.physicsComponents.test.ts如今以.temp后缀保留为 packages/dev/core/test/unit/Physics/babylon.physicsComponents.test.temp带.temp后缀意味着暂时不参与.test.ts的 glob 收集而当前物理模块的正式单元测试已演化为 packages/dev/core/test/unit/Physics/havokPlugin.test.ts。因此按当前仓库结构真正可运行的等价命令应为npm run test -w dev/core -- -i test/unit/Physics/havokPlugin.test.ts-i的匹配并不要求绝对精确到目录层级只要过滤参数能与测试文件的相对路径片段吻合即可命中同样也可以省略-i直接用位置参数过滤例如npm run test -w dev/core -- test/unit/Physics/havokPlugin.test.ts测试是如何被发现的vitest 配置剖析要正确理解单文件命令为什么能命中用例需要看仓库根的 vitest.config.mts。它通过createProjectConfig(type)生成按类型划分的 vitest 项目其中unit项目的收集规则为include: [packages/**/test/${type}/**/*.test.{ts,tsx}]即只收集packages/**/test/unit/**/*.test.{ts,tsx}形式、且以.test.ts或.test.tsx结尾的文件——这正是dev/core用例位于test/unit/且必须带.test.后缀的原因。该配置还包含几个对跑通测试至关重要的细节pool: forks改用子进程而非 worker 线程执行测试。配置注释解释了原因Babylon.js 源码存在很深的副作用导入链着色器、场景组件等异步解析默认线程池下待解析模块可能存活超过测试结束时间而触发EnvironmentTeardownErrorfork 进程可以干净退出。TC39 装饰器转换仓库已迁移到 TC39 Stage 3 装饰器配合accessor关键字配置关闭 Oxcoxc: false并注册esbuildDecoratorPlugin在预处理阶段用 esbuild 把 TS/TSX 源码先降级为可执行的 JSvitest.setup.ts 中还会为Symbol.metadata打 polyfill否则 Node 无法解析装饰器语法。路径别名映射convertPathsToAliases()把根 tsconfig.json 中compilerOptions.paths的每一项转换为 vitest 的resolve.alias例如core/*→./packages/dev/core/src/*、dev/core→./packages/dev/core/src。这正是测试源码里import { Scene } from core/scene这类不带相对路径的导入能够解析的底层机制。类型包 stubbabylonjs-gltf2interface是纯类型包没有 JS 入口配置将其解析到 packages/public/glTF2Interface/babylonjs-gltf2interface.stub.ts避免 glTF 相关测试因找不到运行时入口而失败。测试环境unit项目使用environment: node且setupFiles指向 vitest.setup.ts内含draco3dgltf的 mock。依赖浏览器 DOM、需要 Puppeteer/Playwright 的集成、性能与交互测试不在此列由根 package.json 中的test:visualization、test:integration、test:performance等脚本通过 playwright.config.ts 单独运行。单测用例长什么样以 Physics 模块为例原文档选中的正是物理模块的测试当前对应的实现是 packages/dev/core/test/unit/Physics/havokPlugin.test.ts。该文件演示了dev/core单元测试的典型写法用vi.fn()构造 Havok 原生 API 的 mock如HP_World_Step、HP_World_GetCollisionEvents、HP_World_AddBody再通过Object.assign(Object.create(HavokPlugin.prototype), {...})注入到插件实例上从而在无 WASM 环境下验证插件逻辑用describe(HavokPlugin world region configuration)等分组组织断言例如验证disableWorldRegions: true时只创建一个默认 worldexpect(hknp.HP_World_Create).toHaveBeenCalledOnce()、验证最后一个刚体被移除后非默认 world 会在executeStep时被释放、默认 world 永不释放等行为使用vi.spyOn(FloatingOriginCurrentScene, getScene).mockReturnValue(...)模拟漂浮原点场景覆盖刚体跨 world region 传送PhysicsPrestepType.TELEPORT的释放逻辑。保留的 packages/dev/core/test/unit/Physics/babylon.physicsComponents.test.temp 则是一份偏 E2E 风格的历史用例它通过loadScript从外部加载ammo.js基于NullEngineScene.enablePhysics验证PhysicsImpostor、applyImpulse、onBeforePhysicsObservable等注入到Scene/AbstractMesh上的物理组件行为。对比两份文件可以看出dev/core测试从依赖真实插件加载到纯 mock 插件接口的演进趋势——后者更快、更稳也更适合纳入vitest run的日常循环。在 CI 与可视化测试体系中的定位dev/core的单元测试只是 Babylon.js 完整质量体系的第一环。根 package.json 中的相关脚本包括npm run test:unitvitest run --projectunit即本文讨论的纯 Node 单元测试npm run test:visualization/test:visualization:ui通过 playwright.config.ts 跑浏览器渲染验证npm run test:integrationPlaywright 集成测试 内存泄漏测试tools/memory-leak-testsnpm run test:performance、npm run test:interactions性能与交互专项。在 CI 环境下vitest.config.mts 会把 reporter 切换为[default, junit]并输出./junit.xml方便接入测试报告系统。日常开发建议按包内全量 → 单文件 → 单用例逐级缩小范围先npm run test -w dev/core确认包内无回归改动局部模块时再用-i只跑相关文件以缩短反馈回路。常见问题与排查要点过滤路径没命中用例检查路径是否带test/unit/前缀、文件名是否以.test.ts/.test.tsx结尾.temp后缀的用例不会被收集并确认是从仓库根目录执行npm run ... -w dev/core而不是把工作目录切进包内再直接敲vitest。装饰器或accessor语法报错确认走的是仓库根 vitest.config.mts含esbuildDecoratorPlugin与oxc: false而不是用独立的简化 vitest 配置。core/*等裸导入解析失败别名的源头是根 tsconfig.json 的paths例如core/*: [./packages/dev/core/src/*]、dev/core: [./packages/dev/core/src]修改或新增别名时需保证 vitest 配置中的convertPathsToAliases能同步识别。环境版本不符dev/core及其依赖使用较新的 Node/TypeScriptTypeScript ~6.x、Vite 8、Vitest 4.x请按根engines字段选择 Node 版本。小结dev/core的 readme.md 用两行命令概括了核心测试工作流背后支撑它的是一整套精心设计的 vitest 工程按test/unit目录约定的 glob 收集、forks进程池、TC39 装饰器的 esbuild 预处理、tsconfig 路径别名的运行时解析以及以havokPlugin.test.ts为代表的纯 mock 单元测试范式。掌握npm test与npm run test -w dev/core -- -i file这两条命令并结合本仓库的配置与用例理解其运作机制即可在修改引擎源码时快速获得精准、可靠的测试反馈。赞分享图形学游戏开发3D渲染【免费下载链接】Babylon.jsBabylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.项目地址https://gitcode.com/gh_mirrors/ba/Babylon.js点击查看免费下载相关推荐ESLint 单元测试运行指南从全量测试到单用例调试的完整实践ESLint 单元测试运行指南从全量测试到单用例调试的完整实践 本篇指南以 ESLint 官方贡献文档《Run the Tests》为核心骨架结合仓库内的开发工具Lint静态分析代码质量Readest 测试技巧用 pnpm Vitest 精准运行单个测试文件避开 -- 分隔符陷阱Readest 测试技巧用 pnpm Vitest 精准运行单个测试文件避开 分隔符陷阱 导读 本文整理 Readest 项目中一条经过实战验证的测试桌面应用跨平台前端Egg 框架单元测试实战指南从 Vitest 运行器到 Controller / Service / Extend 全覆盖Egg 框架单元测试实战指南从 Vitest 运行器到 Controller / Service / Extend 全覆盖 本篇指南以 Egg 官方文档 si后端Web框架上一篇SketchUp STL插件完整指南3D打印文件转换的终极解决方案下一篇5步掌握NHSE动物森友会存档编辑终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Babylon.js @dev/core 包测试指南：从全量 vitest 运行到单文件精确调试
图形学游戏开发3D渲染【免费下载链接】Babylon.jsBabylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.项目地址https://gitcode.com/gh_mirrors/ba/Babylon.js点击查看免费下载Babylon.js 的核心渲染引擎源码以dev/core工作区包的形式存放于 packages/dev/core其 readme.md 用最简篇幅给出了两条测试命令运行完整测试套件npm test与仅运行单个测试文件npm run test -w dev/core -- -i file。本文以这两条命令为骨架结合仓库根目录与包级的package.json脚本、vitest.config.mts 的项目配置以及 packages/dev/core/test/unit/Physics 下的真实测试用例讲解如何在 monorepo 中跑通、缩小并理解dev/core的单元测试帮助开发者高效验证对引擎源码的改动。dev/core 是什么测试对象与适用前提dev/core是 Babylon.js monorepo 中面向开发阶段的 TypeScript 源码包包含了引擎Engine/NullEngine、场景Scene、网格Meshes、材质Materials、相机Cameras、物理Physics、粒子、动画等核心模块的实现源码位于 packages/dev/core/src。其包清单定义在 packages/dev/core/package.jsonmain/module/types均指向dist/index属于private: true的工作区内部包不直接对外发布。使用本文命令前需满足仓库根 package.jsonengines字段声明的环境node ^20.19.0 || 22.13.0 23.0.0 || 24.0.0 25.0.0npm 11.18.0。仓库通过根 package.json 的workspaces: [packages/**/*]与 lerna.json 的packages: [packages/**/*]管理多包依赖因此npm run test -w dev/core这种 workspace 语法可以精确锁定目标包。快速开始运行dev/core完整测试套件原文档给出的第一条命令是npm test在仓库根目录执行时它等价于根 package.json 中test: vitest run --projectunit即只运行unit测试项目。而在 packages/dev/core/package.json 内部dev/core自己的测试脚本是test: vitest run。两种方式的差异在于npm test根按 vitest.config.mts 中projects配置的unit项目统一调度理论上会扫描所有包的单元测试npm run test -w dev/core包级把 vitest 的启动目录限定在dev/core只收集该包范围内的用例迭代单个包时更聚焦。dev/core的单元测试集中存放在 packages/dev/core/test/unit按引擎模块分目录组织例如Animations/、Cameras/、Meshes/、Physics/、Particles/、Scene/等顶层还有babylon.assetContainer.test.ts、babylon.node.test.ts、babylon.scene.materials.test.ts等场景级用例。单文件测试文档命令的逐段拆解原文档给出的第二条命令是npm run test -w dev/core -- -i test/Physics/babylon.physicsComponents.test.ts把它拆开来看各段含义如下npm run test -w dev/core运行dev/core包内的test脚本即vitest run--npm 的分隔符其后所有参数原样透传给vitest-i globvitest 的--include过滤选项指示本次运行只收集匹配该模式或路径片段的测试文件。其中-i后跟的路径是相对于包根目录的。需要特别提醒原文档写作时的测试路径布局与当前仓库略有出入。当前仓库中dev/core的测试统一放在test/unit/之下而不是test/且原文档提到的babylon.physicsComponents.test.ts如今以.temp后缀保留为 packages/dev/core/test/unit/Physics/babylon.physicsComponents.test.temp带.temp后缀意味着暂时不参与.test.ts的 glob 收集而当前物理模块的正式单元测试已演化为 packages/dev/core/test/unit/Physics/havokPlugin.test.ts。因此按当前仓库结构真正可运行的等价命令应为npm run test -w dev/core -- -i test/unit/Physics/havokPlugin.test.ts-i的匹配并不要求绝对精确到目录层级只要过滤参数能与测试文件的相对路径片段吻合即可命中同样也可以省略-i直接用位置参数过滤例如npm run test -w dev/core -- test/unit/Physics/havokPlugin.test.ts测试是如何被发现的vitest 配置剖析要正确理解单文件命令为什么能命中用例需要看仓库根的 vitest.config.mts。它通过createProjectConfig(type)生成按类型划分的 vitest 项目其中unit项目的收集规则为include: [packages/**/test/${type}/**/*.test.{ts,tsx}]即只收集packages/**/test/unit/**/*.test.{ts,tsx}形式、且以.test.ts或.test.tsx结尾的文件——这正是dev/core用例位于test/unit/且必须带.test.后缀的原因。该配置还包含几个对跑通测试至关重要的细节pool: forks改用子进程而非 worker 线程执行测试。配置注释解释了原因Babylon.js 源码存在很深的副作用导入链着色器、场景组件等异步解析默认线程池下待解析模块可能存活超过测试结束时间而触发EnvironmentTeardownErrorfork 进程可以干净退出。TC39 装饰器转换仓库已迁移到 TC39 Stage 3 装饰器配合accessor关键字配置关闭 Oxcoxc: false并注册esbuildDecoratorPlugin在预处理阶段用 esbuild 把 TS/TSX 源码先降级为可执行的 JSvitest.setup.ts 中还会为Symbol.metadata打 polyfill否则 Node 无法解析装饰器语法。路径别名映射convertPathsToAliases()把根 tsconfig.json 中compilerOptions.paths的每一项转换为 vitest 的resolve.alias例如core/*→./packages/dev/core/src/*、dev/core→./packages/dev/core/src。这正是测试源码里import { Scene } from core/scene这类不带相对路径的导入能够解析的底层机制。类型包 stubbabylonjs-gltf2interface是纯类型包没有 JS 入口配置将其解析到 packages/public/glTF2Interface/babylonjs-gltf2interface.stub.ts避免 glTF 相关测试因找不到运行时入口而失败。测试环境unit项目使用environment: node且setupFiles指向 vitest.setup.ts内含draco3dgltf的 mock。依赖浏览器 DOM、需要 Puppeteer/Playwright 的集成、性能与交互测试不在此列由根 package.json 中的test:visualization、test:integration、test:performance等脚本通过 playwright.config.ts 单独运行。单测用例长什么样以 Physics 模块为例原文档选中的正是物理模块的测试当前对应的实现是 packages/dev/core/test/unit/Physics/havokPlugin.test.ts。该文件演示了dev/core单元测试的典型写法用vi.fn()构造 Havok 原生 API 的 mock如HP_World_Step、HP_World_GetCollisionEvents、HP_World_AddBody再通过Object.assign(Object.create(HavokPlugin.prototype), {...})注入到插件实例上从而在无 WASM 环境下验证插件逻辑用describe(HavokPlugin world region configuration)等分组组织断言例如验证disableWorldRegions: true时只创建一个默认 worldexpect(hknp.HP_World_Create).toHaveBeenCalledOnce()、验证最后一个刚体被移除后非默认 world 会在executeStep时被释放、默认 world 永不释放等行为使用vi.spyOn(FloatingOriginCurrentScene, getScene).mockReturnValue(...)模拟漂浮原点场景覆盖刚体跨 world region 传送PhysicsPrestepType.TELEPORT的释放逻辑。保留的 packages/dev/core/test/unit/Physics/babylon.physicsComponents.test.temp 则是一份偏 E2E 风格的历史用例它通过loadScript从外部加载ammo.js基于NullEngineScene.enablePhysics验证PhysicsImpostor、applyImpulse、onBeforePhysicsObservable等注入到Scene/AbstractMesh上的物理组件行为。对比两份文件可以看出dev/core测试从依赖真实插件加载到纯 mock 插件接口的演进趋势——后者更快、更稳也更适合纳入vitest run的日常循环。在 CI 与可视化测试体系中的定位dev/core的单元测试只是 Babylon.js 完整质量体系的第一环。根 package.json 中的相关脚本包括npm run test:unitvitest run --projectunit即本文讨论的纯 Node 单元测试npm run test:visualization/test:visualization:ui通过 playwright.config.ts 跑浏览器渲染验证npm run test:integrationPlaywright 集成测试 内存泄漏测试tools/memory-leak-testsnpm run test:performance、npm run test:interactions性能与交互专项。在 CI 环境下vitest.config.mts 会把 reporter 切换为[default, junit]并输出./junit.xml方便接入测试报告系统。日常开发建议按包内全量 → 单文件 → 单用例逐级缩小范围先npm run test -w dev/core确认包内无回归改动局部模块时再用-i只跑相关文件以缩短反馈回路。常见问题与排查要点过滤路径没命中用例检查路径是否带test/unit/前缀、文件名是否以.test.ts/.test.tsx结尾.temp后缀的用例不会被收集并确认是从仓库根目录执行npm run ... -w dev/core而不是把工作目录切进包内再直接敲vitest。装饰器或accessor语法报错确认走的是仓库根 vitest.config.mts含esbuildDecoratorPlugin与oxc: false而不是用独立的简化 vitest 配置。core/*等裸导入解析失败别名的源头是根 tsconfig.json 的paths例如core/*: [./packages/dev/core/src/*]、dev/core: [./packages/dev/core/src]修改或新增别名时需保证 vitest 配置中的convertPathsToAliases能同步识别。环境版本不符dev/core及其依赖使用较新的 Node/TypeScriptTypeScript ~6.x、Vite 8、Vitest 4.x请按根engines字段选择 Node 版本。小结dev/core的 readme.md 用两行命令概括了核心测试工作流背后支撑它的是一整套精心设计的 vitest 工程按test/unit目录约定的 glob 收集、forks进程池、TC39 装饰器的 esbuild 预处理、tsconfig 路径别名的运行时解析以及以havokPlugin.test.ts为代表的纯 mock 单元测试范式。掌握npm test与npm run test -w dev/core -- -i file这两条命令并结合本仓库的配置与用例理解其运作机制即可在修改引擎源码时快速获得精准、可靠的测试反馈。赞分享图形学游戏开发3D渲染【免费下载链接】Babylon.jsBabylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.项目地址https://gitcode.com/gh_mirrors/ba/Babylon.js点击查看免费下载相关推荐ESLint 单元测试运行指南从全量测试到单用例调试的完整实践ESLint 单元测试运行指南从全量测试到单用例调试的完整实践 本篇指南以 ESLint 官方贡献文档《Run the Tests》为核心骨架结合仓库内的开发工具Lint静态分析代码质量Readest 测试技巧用 pnpm Vitest 精准运行单个测试文件避开 -- 分隔符陷阱Readest 测试技巧用 pnpm Vitest 精准运行单个测试文件避开 分隔符陷阱 导读 本文整理 Readest 项目中一条经过实战验证的测试桌面应用跨平台前端Egg 框架单元测试实战指南从 Vitest 运行器到 Controller / Service / Extend 全覆盖Egg 框架单元测试实战指南从 Vitest 运行器到 Controller / Service / Extend 全覆盖 本篇指南以 Egg 官方文档 si后端Web框架上一篇SketchUp STL插件完整指南3D打印文件转换的终极解决方案下一篇5步掌握NHSE动物森友会存档编辑终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考