桌面应用跨平台前端【免费下载链接】readestReadest is a modern, feature-rich ebook reader designed for avid readers offering seamless cross-platform access, powerful tools, and an intuitive interface to elevate your reading experience.项目地址https://gitcode.com/gh_mirrors/re/readest点击查看免费下载导读本文整理 Readest 项目中一条经过实战验证的测试运行经验如何用pnpm test path/pnpm test:browser path精准运行单个测试文件。核心结论是——不要在路径前添加--分隔符否则 Vitest 会忽略文件过滤并运行全部测试同时本文会说明在 CI 后台 shell 中如何用vitest run保证一次性执行以及为什么必须保留dotenv包装与 src/utils/supabase.ts 的导入期环境变量解码强相关。读完你可以掌握 Readest 各测试通道的正确单测命令、底层参数透传原理以及一条可复制的单文件一次性运行命令。背景Readest 的多通道 Vitest 测试体系Readest 的测试栈以 Vitest 为核心但按运行环境拆分为多个独立通道均由 apps/readest-app/package.json 中的 scripts 驱动命令底层脚本配置适用场景pnpm testdotenv -e .env -e .env.test.local -- vitestvitest.config.mtsjsdom 环境纯逻辑、工具函数、服务层单测pnpm test:browserdotenv -e .env -e .env.test.local -- vitest run --config vitest.browser.config.mtsvitest.browser.config.mtsPlaywright 驱动真实 Chromium依赖 Web Worker、SharedArrayBuffer、OPFS 等浏览器 API 的用例pnpm test:tauribash scripts/test-tauri.shvitest.tauri.config.mtsTauri WebView 内的 IPC 集成测试pnpm test:androidbash scripts/test-android.shvitest.android.config.mtsAndroid 真机/模拟器手势与原生行为 E2E两个主要通道的测试文件按命名约定分流jsdom 单测为*.test.ts/*.test.tsx浏览器测试为*.browser.test.ts/*.browser.test.tsx见 vitest.browser.config.mts 的include与 vitest.config.mts 的exclude。更完整的体系说明可参考 apps/readest-app/docs/testing.md。正确姿势路径直接跟在命令后不加--在 Readest 中运行单个测试文件正确的命令是# 运行单个 jsdom 单元测试文件 pnpm test src/__tests__/utils/misc.test.ts # 运行单个浏览器测试文件 pnpm test:browser src/__tests__/utils/captured-turn.browser.test.ts关键点路径前不要加--分隔符即不要写成# ❌ 错误示范会导致 Vitest 忽略文件过滤、运行全部测试 pnpm test -- src/__tests__/utils/misc.test.ts pnpm test:browser -- src/__tests__/utils/captured-turn.browser.test.ts为什么--会让过滤失效这与 pnpm 的脚本参数透传机制有关。pnpm test path中pnpm 会把path直接追加到test脚本的命令行末尾由于脚本本身是dotenv ... -- vitest追加后的完整命令为dotenv -e .env -e .env.test.local -- vitest src/__tests__/utils/misc.test.tsVitest 将位置参数path正确解析为测试文件过滤。而加上--后pnpm 透传的是-- pathVitest 在解析自身 CLI 时对--及其后内容的处理方式不同最终结果是文件过滤器被忽略Vitest 按配置跑起全量测试jsdom 通道会遍历 vitest.config.mts 默认 include 的所有src/**/*.test.ts浏览器通道则遍历全部src/**/*.browser.test.ts(x)。验证时看似命令成功执行了但实际上跑的不是你想验证的那个文件极易造成误判。注意项目自有文档 apps/readest-app/docs/testing.md 中的示例仍使用pnpm test -- src/...写法本文所整理的.claude/memory反馈经验表明该写法在当前脚本结构下会导致过滤失效建议以不加--的写法为准。后台 shell 的一次性运行vitest run dotenv 包装原文档还记录了一个针对 CI / 后台 Bash 环境的关键陷阱test脚本是裸的vitest不带run因此在没有 TTY 的后台 shell 中会默认进入 watch 模式进程不会自然退出此时如果再配合| tail之类的管道tail永远等不到 EOF命令会一直挂起。要在后台 shell 中保证一次性执行并正常返回使用以下命令以单元测试为例pnpm exec dotenv -e .env -e .env.test.local -- vitest run path这条命令拆解如下片段作用pnpm exec dotenv通过 pnpm 调用dotenv-cli加载环境变量-e .env -e .env.test.local依次加载.env与.env.test.local后者覆盖前者与 package.json 中test脚本的加载方式保持一致-- vitest run path--分隔 dotenv 自身的参数与要执行的命令vitest run强制单次运行、结束后退出path指定测试文件同样的思路可推广到浏览器通道pnpm exec dotenv -e .env -e .env.test.local -- vitest run --config vitest.browser.config.mts path为什么 dotenv 包装是必需的这不是可有可无的装饰Readest 的 src/utils/supabase.ts 在**模块导入时顶层**就会执行atob(process.env[NEXT_PUBLIC_DEFAULT_SUPABASE_URL_BASE64]!)和atob(process.env[NEXT_PUBLIC_DEFAULT_SUPABASE_KEY_BASE64]!)用于从 Base64 编码的环境变量解码 Supabase 的 URL 与匿名 key。一旦环境变量缺失atob(undefined)会立即抛错任何间接 import 了该模块的测试在启动阶段就会失败。dotenv包装确保这些变量在 Vitest 进程启动前就已注入是单文件调试能够跑起来的前提条件。踩坑速查与最佳实践单文件验证优先使用pnpm test src/__tests__/foo.test.ts或pnpm test:browser src/__tests__/foo.browser.test.tsx路径直接追加不加--。后台/CI 环境不要使用裸pnpm test path会进入 watch 模式挂起改用pnpm exec dotenv -e .env -e .env.test.local -- vitest run path。环境变量缺失报错先确认命令前带了-e .env -e .env.test.local这是src/utils/supabase.ts顶层atob解码的硬性要求。通道匹配验证浏览器专属能力Web Worker、WASM 词典、OPFS 存储时用test:browser通道普通工具函数用test通道两者通过 vitest.config.mts 的exclude与 vitest.browser.config.mts 的include互斥划分选错通道会得到文件不存在于该配置或全量误跑的困惑。赞分享桌面应用跨平台前端【免费下载链接】readestReadest is a modern, feature-rich ebook reader designed for avid readers offering seamless cross-platform access, powerful tools, and an intuitive interface to elevate your reading experience.项目地址https://gitcode.com/gh_mirrors/re/readest点击查看免费下载相关推荐Supabase 单测过滤实战用 Vitest 按名称、文件、标签与变更精准运行测试Supabase 单测过滤实战用 Vitest 按名称、文件、标签与变更精准运行测试 本文以 Supabase 仓库中为 AI Agent 编写的 Vites后端前端数据库7个致命测试陷阱GoogleTest帮你避开90%的单元测试坑7个致命测试陷阱GoogleTest帮你避开90%的单元测试坑 在软件开发过程中单元测试是确保代码质量的关键环节但很多开发者常常陷入各种测试陷阱。Goog测试质量保障开发工具Wasp 0.13 测试指南用 Vitest 编写与运行 React 单元测试和组件测试Wasp 0.13 测试指南用 Vitest 编写与运行 React 单元测试和组件测试 本文基于 Wasp 0.13 版本文档 Testing https:Web框架后端前端CLI开发工具上一篇nvim-bqf常见问题解决从安装到使用的完整排错手册下一篇Shardeum缓存策略完全解析内存缓存SQLite优化如何让验证节点跑得更快创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
