tdd在javascript中遵循“先写测试、再写实现、最后重构”循环，jest通过零配置、快速反馈、内置断言与模拟等特性高效支撑该流程。
JavaScript中实现测试驱动开发（TDD），核心是“先写测试，再写实现，最后重构”的循环。Jest不是让TDD自动发生，而是提供快速、隔离、易断言的测试执行环境，帮你高效完成这个循环。
测试驱动开发在JS中的典型流程
以实现一个加法函数为例：
- 第一步：用describe和test写一个失败的测试，比如expect(add(1, 2)).toBe(3) —— 此时add还没定义，测试直接报错
- 第二步：仅写出能让测试通过的最简实现（比如直接return 3），不考虑通用性
- 第三步：补充更多测试用例（如负数、小数、边界值），让测试再次失败，再调整实现
- 第四步：所有测试通过后，才优化代码结构（如提取逻辑、改命名），确保测试仍全部通过
Jest如何支撑这个流程
Jest本身不强制TDD，但它通过几个关键设计让TDD更顺滑：
- 零配置启动：npm init -y 后安装 jest，加一行"test": "jest"到package.json，就能直接运行npm test
- 快照与并行执行：默认启用多进程，单个测试文件改动后只重跑相关测试，反馈通常在毫秒级
- 内置断言与模拟工具：不用额外引入Chai或Sinon —— jest.fn()可轻松模拟函数，mockImplementation控制返回值，expect().toHaveBeenCalledWith()验证调用细节
- 自动Mock与模块隔离：对依赖模块调用jest.mock('./utils')后，整个模块被替换为可控桩，避免副作用干扰TDD节奏
一个真实TDD小例子（带Jest）
目标：写一个filterByType(items, type)，按类型筛选数组对象。
立即学习“Java免费学习笔记（深入）”；
- 先写测试：test('filters items by type', () => { expect(filterByType([{t: 'a'}, {t: 'b'}, {t: 'a'}], 'a')).toEqual([{t: 'a'}, {t: 'a'}]); });
- 运行npm test → 报错“filterByType is not defined” → 符合TDD预期
- 补实现：const filterByType = (items, type) => items.filter(i => i.t === type);
- 测试通过 → 再加一个测试：空数组、type为undefined、属性名不叫t…逐个击破
注意事项：TDD不是为测而测
Jest再强大，也替代不了对需求的理解。常见误区包括：
- 为私有工具函数单独写大量测试，却忽略主流程场景
- 过度mock导致测试“看起来过”，实际集成时出错
- 卡在“怎么测异步”上，其实Jest原生支持async/await和done回调
- 把测试覆盖率当目标，而不是用测试推动设计 —— 覆盖率高但逻辑混乱，不如几个关键路径的清晰测试
