单元测试纳入CI需失败即阻断、通过才放行；推荐Jest或Vitest，配置固化在配置文件，设testEnvironment、覆盖率阈值、setup脚本；CI中用npm ci、显式NODE_ENV=test、禁用彩色输出、控制超时；嵌入构建前与lint合并，产出lcov.info/junit.xml；失败时启用--verbose、上传报告、暴露关键错误。
在 JS 项目中，把单元测试纳入 CI 流水线不是加一行命令就完事，关键是让它真正起到“守门人”作用——失败即阻断，通过才放行。
选对框架并固化配置
推荐用 Jest（零配置、覆盖率内置）或 Vitest（Vite 项目下启动更快）。配置要写进项目根目录的 jest.config.js 或 vitest.config.ts，而不是靠 CLI 参数临时传入。重点配好这几项：
-
testEnvironment：Node 项目设为
'node'，前端项目设为'jsdom' -
collectCoverage 和 coverageThreshold：开启覆盖率收集，并设最低阈值（比如
lines: 80），低于就让流水线失败 - setupFilesAfterEnv：指定初始化脚本（如 mock 全局 fetch、重置模块缓存）
CI 中稳定执行的关键操作
本地能跑不等于 CI 里稳，常见坑都得提前堵住：
- 用 npm ci 而非 npm install：确保依赖树和
package-lock.json严格一致，避免因缓存或版本浮动导致测试行为不一致 - 显式设置 NODE_ENV=test：防止开发/生产环境特有的逻辑干扰测试结果
- 禁用彩色输出和进度条：
--no-color --silent，避免日志解析失败或终端兼容问题 - 超时控制：
--maxWorkers=2防止单测占满资源，--testTimeout=5000避免个别慢用例拖垮整条流水线
与流水线阶段自然衔接
单元测试不是孤立步骤，它该嵌在合理的位置上：
- 放在 构建前：验证代码语法、基础逻辑没问题再打包，省去无效构建浪费
- 和 lint 合并在同一阶段（如
test:ci）：先检查风格，再跑用例，失败统一归因 - 产出可被下游消费的结果：生成
coverage/lcov.info供覆盖率平台解析，或junit.xml供 Jenkins/GitLab 展示测试报告
失败时要有明确反馈
流水线红了，得让人一眼看懂哪错了：
- Jest 加
--verbose（仅在失败时启用），显示具体哪个 test suite 崩了 - 把测试报告上传到 GitLab CI 的
artifacts，或集成到 SonarQube 做长期趋势分析 - 关键错误信息（如未处理的 Promise rejection、全局未捕获异常）要暴露在日志开头，别埋在几百行输出里
