JavaScript测试需分层：单元测试隔离验证函数/类输入输出，用Jest或Vitest；集成测试验证模块协作，用@testing-library/react模拟用户行为；测试应聚焦业务逻辑、精准断言、避免实现细节，并持续维护。
JavaScript 测试的核心是分层验证：单元测试聚焦单个函数或类的行为，集成测试检查多个模块协作是否符合预期。关键不是“写不写”，而是“测什么”和“怎么断言”。
单元测试：从最小可测单元开始
单元测试的目标是隔离被测代码，用可控输入验证输出或副作用。推荐使用 Jest（开箱即用）或 Vitest（轻量、Vite 生态友好）。
- 每个测试文件对应一个源文件（如 utils.js → utils.test.js），命名清晰
- 用 describe 分组逻辑相关测试，用 it/test 描述具体行为（建议用“should”句式，如 “should return true when input is positive number”）
- 避免测试实现细节（比如内部变量名、私有方法），只测公开接口的输入/输出、异常、边界情况
- 对有副作用的函数（如调用 API、修改 DOM、发事件），用 mock 替换依赖。例如：fetch 可 mock 成返回固定 Promise；React 组件中调用的 hook 可用 jest.mock 或自定义 render + act 模拟
集成测试：验证模块组合是否协同工作
集成测试不追求完全隔离，而是把几个紧密耦合的单元（如一个 React 组件 + 它使用的自定义 Hook + 对应的 API Service）一起运行，看整体流程是否通。
- 常见场景：组件渲染后用户点击、输入、等待异步加载完成，再断言 UI 状态变化（如按钮变灰、列表出现数据、错误提示显示）
- 工具上，Jest + @testing-library/react 是主流组合。它鼓励“像用户一样测试”：查文本、找按钮、触发事件，而不是访问组件实例或 state
- 真实 API 调用在集成测试中通常仍需 mock（用 jest.mock 或 MSW 拦截请求），但 mock 的粒度比单元测试粗——比如 mock 整个 service 模块，而非单个 fetch 调用
- 注意异步等待：用 await waitFor 等待状态更新或 DOM 变化，不用 setTimeout 或盲目 await new Promise(resolve => setTimeout(resolve, 100))
测试结构要简洁，断言要精准
一个测试用例最好只验证一个关注点。避免在一个 it 块里塞多个 expect，尤其不要混合不同行为（比如既测成功又测失败）。
立即学习“Java免费学习笔记（深入）”；
- 输入 → 动作 → 断言，三步清晰。例如：render 组件 → fireEvent.click 按钮 → expect(screen.getByText("Loading...")) 存在
- 断言优先选语义化查询：screen.getByRole、getByText、getByLabelText，比 getByTestId 更健壮（不依赖开发添加的 test-id）
- 对错误边界，用 expect(() => fn()).toThrow() 或 await expect(fetchData()).rejects.toThrow() 明确捕获异常
让测试可持续的关键习惯
测试不是一次性的文档，而是活的保障。维护成本低的测试才有长期价值。
- 每次修复 bug，先补一个复现该 bug 的测试用例，再改代码——防止回归
- 重构前确保已有测试覆盖，重构后测试全绿，才说明行为未变
- 定期删掉过时、重复、无法描述业务意图的测试（比如只测 console.log 输出）
- CI 中强制跑测试，且设置覆盖率阈值（如行覆盖率 ≥80%），但不过度追求 100%，重点在核心路径和分支逻辑
