JavaScriptTDD如何实施？

本文深入解析了JavaScript测试驱动开发（TDD）在现代工程实践中的落地要点：强调测试文件与源码同目录、命名规范统一以提升可维护性与IDE体验；倡导用`vi.mock()`精准隔离副作用依赖而非盲目mock，平衡单元隔离与集成校验；指出TDD的核心在于用清晰的行为描述驱动编码节奏，善用`it.todo`占位、单断言单用例和自然语言测试名；并直击CI环境常见陷阱——Node版本不一致、jsdom缺失、模块缓存残留及全局API缺失，给出可立即执行的排查清单。真正卡住开发的，从来不是语法，而是那些隐藏在环境、加载顺序和全局状态里的“幽灵问题”。

测试用例写在哪？和源码放一起还是分离？

绝大多数现代 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 安全。

• 确认 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，防止脚本链路被覆盖

今天关于《JavaScriptTDD如何实施？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！