如何为 pydantic/monty 编写 TypeScript 测试vitest 与 WASM 测试矩阵实战指南【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/montymonty是一个用 Rust 编写、专为 AI 场景打造的极简安全 Python 解释器其 npm 包pydantic/monty让你在 Node.js 中通过崩溃隔离的子进程 Worker、在浏览器中通过 Web Worker WASM 安全地运行不可信 Python 代码。本文带你完整拆解crates/monty-js的 TypeScript 测试体系如何用一套 vitest 配置矩阵同时覆盖「Node 原生绑定、WASM 运行时、真实浏览器」三条执行路径。一、先看懂测试矩阵三套 vitest 配置pydantic/monty的产物有三个入口测试自然也要按入口分工。整个测试矩阵由三份 vitest 配置文件驱动配置文件覆盖范围运行命令前置条件vitest.config.ts__test__/*.spec.ts排除wasm_*.spec.tsnpm test已构建 NAPI 原生绑定vitest.wasm.config.ts__test__/wasm_*.spec.tsnpm run test:wasm先执行npm run build:wasmvitest.browser.config.ts__test__/*.spec.ts排除node_*.spec.tsnpm run test:browser先构建 wasm并安装 Playwright Chromium 三套配置的关键区别只有一组include/exclude默认套件刻意排除wasm_*用例因为它需要预构建的monty_wasm_runtime.wasmWASM 套件只跑wasm_*用例浏览器套件则反向排除node_*用例这些用例会读源码文件、执行 shell 命令无文件系统的浏览器里跑不了。 三套配置都设置了fileParallelism: false和 120 秒超时——因为每个测试都在真实的隔离 Worker 子进程中执行 Python宁可串行慢一点也不要并行抢资源。二、写第一个 spec池化夹具 精简断言所有 spec 文件都在 crates/monty-js/test/ 目录共 23 个文件如 basic.spec.ts、async.spec.ts、pool.spec.ts 等。它们共享两个「地基」文件1️⃣ 池化夹具 helpers.ts核心思想每个 spec 文件只创建一个共享 Worker 池并在beforeAll/afterAll中创建与关闭。setupPool()返回一个run辅助函数——在全新会话中执行一段 Python 代码并返回结果const { run, pool } setupPool() test(simple expression, async () { t.is(await run(1 2), 3) })需要直接管理会话测试会话隔离、状态持久化等时用pool()拿到池子自行checkout()/close()模式参考 basic.spec.ts 中的会话行为用例。2️⃣ 精简断言 assertions.ts没有直接使用expect而是包了一层极简的tis / deepEqual / throws / throwsAsync …并额外提供throws/throwsAsync同时断言错误类型instanceOf: MontySyntaxError与消息是测试解释器异常路径的主力工具assertMemoryError校验MemoryError报错中的字节数且容忍 1KB 误差——因为分配器基线在不同操作系统上会漂移几十个字节精确匹配会让测试变成「平台专属」这是跨平台测试很实用的一招。三、WASM 测试怎么写先构建再导入正确入口WASM 套件wasm_memory_limit、wasm_type_check、wasm_word_size等 spec有两个必须记住的约定必须先行构建 wasm 产物。package.json中build:wasm脚本会用wasm32-wasip1目标编译 monty-wasm-runtime仓库顶层的 Makefile 提供了make test-wasm一键完成「构建 测试」make test-wasm从/wasm入口导入 API而不是包主入口。以 wasm_memory_limit.spec.ts 为例它特意写import { Monty, MontyCrashedError } from pydantic/monty/wasm——因为从主入口导入会拉进 NAPI 原生加载器而 WASM 套件的环境里根本没有构建原生模块。这套用例还示范了「崩溃语义」的测试写法软性超限抛出可捕获的MontyRuntimeError实例存活硬性超限则 wasm 模块直接 trap表现为MontyCrashedError——wasm 模块没有退出码无法分类为 MemoryError这正是与 Node 原生 Worker 路径的行为差异点值得单独成用例。四、浏览器测试vitest browser Playwrightvitest.browser.config.ts 展示了在无 Node 环境的浏览器中跑同一批用例的三件事真实浏览器启用vitest/browserprovider 为playwrightheadless Chromium 单实例打桩node:内置模块自定义 Vite 插件把所有node:开头的导入解析到 node-builtins-stub.ts一个会抛错的桩别名把pydantic/monty/node指向 node-stubs.ts排除 Node 专属用例exclude: [__test__/node_*.spec.ts]。对应命令Makefile 中会自动先装 Chromiummake test-browser⚠️ 一个容易踩的坑浏览器模式下 Worker 数量受限setupPool()内部会自动为 browser 环境加maxCheckoutsPerWorker: 1见 helpers.ts。五、跨环境通用技巧环境探测 条件跳过env.ts 用typeof window判断运行环境导出skipIfBrowser/skipIfNode。同一 spec 文件在 Node 套件和浏览器套件中都会执行用它们让用例「各走各的路」而不是拆成两份文件会话一律close()归还参考 basic.spec.ts 中try / finally的结构避免会话泄漏影响后续用例公开 API 契约测试public_api.spec.ts 与 node_protocol_version.spec.ts 直接读取源码文件、断言导出面保证包入口././node/./wasm见 package.json 的exports字段不被意外破坏。六、推荐运行顺序清单 ✅步骤命令目的1make install-js安装 JS 依赖2npm test在crates/monty-jsNode 原生路径全量回归3make test-wasmWASM Worker 路径Node 驱动无需浏览器4make test-browser真实 Chromium 中的 WASM 路径三条命令跑绿才算一次完整的跨平台回归。延伸阅读包使用与 API 文档crates/monty-js/README.md测试支撑代码crates/monty-js/test-support/浏览器 Worker 运行时源码crates/monty-js/ts/worker/WASM 运行时 cratecrates/monty-wasm-runtime/总结一句话一份用例、三套配置、两个共享地基池化夹具 精简断言就是pydantic/monty用 vitest 同时守护 Node / WASM / 浏览器三条路径的完整秘诀。【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/monty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考