推荐测试文件与源码同级共存，命名一致（如formatdate.js对应formatdate.test.js），按需细分.unit/.integration，禁用__tests__等反模式，并辅以工具链校验和ci覆盖率管控。
在 JavaScript 项目中规范单元测试目录结构，核心是让测试文件与源码保持就近共存、命名一致、层级对齐，同时兼顾工具链支持（如 Jest、Vitest）和团队可维护性。
推荐结构：测试文件与源码同级（colocated）
这是目前主流且最易维护的方式，尤其适合中大型项目：
- 每个模块（函数、组件、工具类）的测试文件放在同一目录下，以
.test.js或.spec.js结尾 - 例如：
src/utils/formatDate.js→ 对应src/utils/formatDate.test.js - 组件同理：
src/components/Button.jsx→src/components/Button.test.jsx - Jest/Vitest 默认会自动识别
**/*.test.*和**/*.spec.*文件，无需额外配置扫描路径
按功能划分测试类型（可选但建议）
当单个模块测试逻辑复杂时，可进一步细分测试文件，提升可读性：
-
Button.test.jsx：主测试文件，覆盖主要用例和集成行为 -
Button.unit.test.jsx：纯单元视角，mock 所有依赖，专注内部逻辑 -
Button.integration.test.jsx：测试组件与真实子组件或 hooks 的协作 - 注意：这类拆分不是必须，但团队约定后能避免“一个 test 文件塞 200 行”问题
避免常见反模式
以下结构看似“整齐”，实际会降低开发效率和可维护性：
- ❌ 全局
__tests__目录（如__tests__/utils/formatDate.test.js）—— 文件移动时容易遗漏同步更新测试路径 - ❌
test/根目录平铺所有测试 —— 随着项目增长，难以定位对应源码，IDE 跳转不直观 - ❌ 测试文件名不匹配源码（如
dateHelper.test.js对应formatDate.js）—— 破坏命名一致性，增加认知负担 - ❌ 混用
.test.js和.spec.js—— 统一后缀更利于工具识别和 lint 规则收敛
配套建议：轻量约定 + 工具辅助
光靠目录结构不够，需搭配简单机制保障落地：
- 在
package.json的test脚本中明确指定测试匹配模式，如："test": "vitest"（Vitest 默认支持）或"test": "jest --collectCoverageFrom='src/**/*.{js,jsx}'" - 添加 ESLint 插件（如
eslint-plugin-jest），校验测试文件是否缺失、命名是否规范 - CI 中启用
--coverage并设置阈值，确保新增模块被测试覆盖 - 新模块 PR 时，要求提交时包含对应
.test.*文件（可通过 commit hook 或 MR 模板提醒）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
