javascript测试如何做_怎样编写单元测试和集成测试？_网络技术

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，尤其不要混合不同行为（比如既测成功又测失败）。

输入 → 动作 → 断言，三步清晰。例如：render 组件 → fireEvent.click 按钮 → expect(screen.getByText("Loading...")) 存在
断言优先选语义化查询：screen.getByRole、getByText、getByLabelText，比 getByTestId 更健壮（不依赖开发添加的 test-id）
对错误边界，用 expect(() => fn()).toThrow() 或 await expect(fetchData()).rejects.toThrow() 明确捕获异常

测试不是一次性的文档，而是活的保障。维护成本低的测试才有长期价值。