测试文件应与源码同目录，命名如 utils.test.js；优先用 vi.mock() 隔离副作用依赖，避免过度 mock；CI 需统一 Node 版本、配置 jsdom 环境并显式调用 npx vitest –run。
测试用例写在哪？和源码放一起还是分离？
绝大多数现代 JavaScript 项目把测试文件和源码放在同一目录，后缀用 .test.js 或 .spec.js（比如 utils.js 对应 utils.test.js）。这样 IDE 跳转方便，重构时也不容易漏掉测试。不推荐统一塞进 __tests__/ 目录——路径变长、引用易出错，尤其在使用 Vite 或 Next.js 的模块解析场景下，import 路径容易因别名或 baseUrl 配置失效。
- VS Code 中按住 Ctrl（或 Cmd）点击测试文件里的
import，应能直接跳到对应源码函数 - 如果用了 TypeScript，确保
tsconfig.json的include字段包含**/*.test.ts - Vite 项目中，
vitest默认只运行.test.*和.spec.*文件，无需额外配置入口
如何让 describe 和 it 真正驱动开发？
“先写测试”不是指堆满断言，而是用测试描述行为边界：输入什么、期望输出什么、异常怎么处理。比如写一个 parseQuery 函数，第一轮测试只覆盖空字符串和基础键值对，不急着写 URL 编码解码逻辑。
- 用
it.todo('handles % encoded values')占位未实现的分支，Vitest 会标为 skipped，比注释更醒目 - 避免在
it块里写多个expect断言验证不同维度——拆成多个it，失败时定位更快 - 测试名用完整句子：
it('returns null when input is undefined'，而不是it('undefined case')
vi.mock() 什么时候必须用？又为什么常被误用？
当测试模块依赖外部副作用（如 fetch、localStorage、第三方 SDK 初始化）时，vi.mock() 是唯一可控方式。但它不是用来“隔离所有依赖”的银弹——过度 mock 会让测试失去对集成行为的校验能力。
- 真实调用
fetch？用vi.stubGlobal('fetch', mockFetch)更轻量，且保留请求参数结构 - mock 模块前，确认该模块是否已被其他测试导入；否则需在
beforeEach中调用vi.resetModules() - 不要 mock 工具函数（如
lodash的debounce）来“让测试快一点”——这掩盖了真实性能瓶颈
CI 环境跑不通 vitest --run？检查这三个点
Vitest 在 CI 中失败，80% 出在环境假设不一致：DOM API、Node 版本、模块解析规则。本地能过不等于 CI 安全。
立即学习 “Java 免费学习笔记（深入）”；
- 确认 CI 使用的 Node 版本与本地一致（尤其
node:20+的test全局 API 可能被低版本忽略） - 如果测试含 DOM 操作，CI 必须启用
--browser或预装jsdom并在vitest.config.ts中配environment: 'jsdom' - GitLab CI 或 GitHub Actions 中，避免用
npm test别名——直接写死npx vitest --run --coverage，防止脚本链路被覆盖
真正卡住人的，往往不是框架语法，而是测试文件加载顺序、模块缓存残留、以及 CI 容器里那个没声明的 globalThis.crypto。
