为什么我们需要测试?
我们的 React+TypeScript 业务组件库已经稳定运行了一段时间,主要承载各类UI展示组件,如卡片、通知等。项目初期,迫于紧张的开发周期,我们暂时搁置了自动化测试的引入。当时团队成员对组件逻辑了如指掌,即便没有测试也能游刃有余。
然而随着时间推移,问题逐渐显现。当新成员加入或老组件需要迭代时,我们常常陷入两难:修改代码可能破坏原有功能,但不修改又无法满足新需求。特别是在处理那些具有多种交互状态的复杂组件时,手动测试变得既耗时又不可靠。这时,引入自动化测试的必要性就凸显出来了。
搭建测试环境
依赖安装
我们首先从安装核心测试依赖开始,这些工具将构成我们测试体系的基础框架:
- 测试运行核心:jest和jsdom环境包
- TypeScript支持:确保类型安全的测试环境
- React测试工具:专门为React组件设计的测试工具链
javascript
npm install jest jest-environment-jsdom @types/jest ts-jest @testing-library/react @testing-library/jest-dom @testing-library/user-event --save-dev
配置Jest
创建jest.config.ts配置文件时,有几个关注点:
- 针对TypeScript项目的特殊处理
- 浏览器环境的模拟
- 测试初始化流程
- 文件转换规则
javascript
module.exports = {
preset: "ts-jest", // 为 TypeScript 项目准备的 Jest 配置预设
testEnvironment: "jsdom", // 测试运行在模拟的浏览器环境中
setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"], // 指定在测试环境初始化后立即执行的文件
transform: {
"^.+\\.(ts|tsx)$": "ts-jest", // 使用 ts-jest 处理所有 .ts 和 .tsx 文件
},
testPathIgnorePatterns: ["/node_modules/", "/dist/"], // 忽略指定目录下的测试文件
moduleFileExtensions: ["ts", "tsx", "js", "jsx", "json", "node"], // 定义 Jest 能识别的模块文件扩展名
};
export {}; // 使文件成为模块
创建jest.setup.ts文件引入断言库:
javascript
import "@testing-library/jest-dom";
TypeScript配置
修改tsconfig.json包含测试相关文件:
javascript
{
"include": [
"src",
"jest.config.ts",
"jest.setup.ts",
"__mocks__/**/*.ts"
]
}
测试用例编写
我们以一个通知组件为例,该组件有两种UI形态:
- 标题和描述组合的时间内容文案提示
- 带有喇叭图标的提示,点击关闭按钮时调用接口保存用户状态
特殊依赖处理
组件中有三类特殊引入需要处理:
javascript
import './index.less';
import { noticeIcon, closeIcon } from "$src/common/icon";
import request from "$src/request";
1、处理 CSS/LESS 资源
Jest 默认无法解析 CSS/LESS 文件,我们可以通过配置将其模拟为空对象:
javascript
// jest.config.js
module.exports = {
moduleNameMapper: {
"\\.(less|css)$': '<rootDir>/__mocks__/styleMock.ts", // 指向一个空文件
},
};
// __mocks__/styleMock.ts
module.exports = {};
2、配置路径别名
对于 $src
这样的路径别名,需要在 Jest 配置中映射:
javascript
// jest.config.js
module.exports = {
moduleNameMapper: {
'^\\$src/(.*)$': '<rootDir>/src/$1',
},
};
3、模拟图标资源
对于图标这类静态资源,我们可以在测试文件中直接模拟:
javascript
// __tests__/index.test.tsx
jest.mock('$src/common/icon', () => ({
noticeIcon: 'notice-icon-path',
closeIcon: 'close-icon-path',
}));
4、模拟 API 请求
对于网络请求模块,我们可以将其转换为 Jest 模拟函数:
javascript
// __tests__/index.test.tsx
import request from '$src/request';
const mockedRequest = request as jest.MockedFunction<typeof request>;
jest.mock('$src/request', () => ({
__esModule: true, // 标识这是 ES Module
default: jest.fn(() => Promise.resolve({ data: {} })),
}));
通过以上配置,我们能够有效地隔离组件测试环境,专注于组件逻辑本身的测试,而不受样式、静态资源和网络请求等外部因素的影响。
基础测试框架搭建
我们首先建立测试的基本结构:
javascript
describe("Notification组件", () => {
// 公共props定义
const baseProps = {
body: {},
tokenId: "test-token",
urlPrefix: "https://api.example.com",
};
// 每个测试用例前的清理工作
beforeEach(() => {
jest.clearAllMocks();
mockedRequest.mockReset();
});
});
核心测试场景覆盖
在配置好 Jest 测试环境后,我们将针对通知组件编写全面的测试用例。该组件具有两种展示形态和交互逻辑,我们将从四个关键维度进行测试覆盖:
1、边界情况测试
我们首先考虑最极端的场景------当传入无效props时,组件是否能够优雅处理:
javascript
it("当传入无效body时应安全地返回null", () => {
const { container } = render(<Notification {...baseProps} body={null} />);
expect(container.firstChild).toBeNull();
});
2、日期类型展示验证
对于日期类型的通知,我们需要确认:
- 关键文本是否正确渲染
- DOM结构是否符合预期
- 样式类是否准确应用
javascript
it("应正确渲染日期类型通知", () => {
render(<Notification {...dateProps} />);
expect(screen.getByText("今日公告")).toBeInTheDocument();
expect(screen.getByText("2023-06-15")).toBeInTheDocument();
const dateContainer = screen.getByText("今日公告").parentElement;
expect(dateContainer).toHaveClass("notice-header-date");
});
3、广播类型交互测试
广播通知的测试更加复杂,需要验证:
- 初始状态下的元素展示
- 图标资源是否正确加载
- 点击关闭后的行为
javascript
it("点击关闭按钮后应隐藏通知内容", async () => {
render(<Notification {...broadcastProps} />);
const closeButton = screen.getAllByRole("img")[1].parentElement;
fireEvent.click(closeButton!);
await waitFor(() => {
expect(screen.queryByText("重要通知内容")).not.toBeInTheDocument();
});
});
4、网络请求场景全覆盖
对于涉及API调用的场景,我们设计了多维度测试:
- 正常请求流程
- 无请求场景请求
- 失败处理
- 请求中的状态管理
javascript
describe("网络请求测试", () => {
const broadcastPropsWithCloseUrl = {
...baseProps,
body: {
type: BROADCAST_TYPE,
content: "重要通知内容",
closeUrl: "/close-notice",
},
};
const broadcastPropsWithoutCloseUrl = {
...baseProps,
body: {
type: BROADCAST_TYPE,
content: "重要通知内容",
// 没有closeUrl
},
};
it("点击关闭时应该发送请求", async () => {
// 模拟请求成功
mockedRequest.mockResolvedValue({ data: {} });
render(<Notification {...broadcastPropsWithCloseUrl} />);
const closeButton = screen.getAllByRole("img")[1].parentElement;
await act(async () => {
fireEvent.click(closeButton!);
});
//验证请求参数
expect(request).toHaveBeenCalledWith({
url: "https://api.example.com/close-notice",
method: "post",
data: {},
headers: {
tokenId: "test-token",
},
});
// 验证UI更新
expect(screen.queryByText("重要通知内容")).not.toBeInTheDocument();
});
it("当没有closeUrl时不发送请求", async () => {
render(<Notification {...broadcastPropsWithoutCloseUrl} />);
const closeButton = screen.getAllByRole("img")[1].parentElement;
await act(async () => {
fireEvent.click(closeButton!);
});
expect(request).not.toHaveBeenCalled();
// 验证UI仍然会更新
expect(screen.queryByText("重要通知内容")).not.toBeInTheDocument();
});
it("请求失败时仍然关闭通知", async () => {
// 模拟请求失败
mockedRequest.mockResolvedValue(new Error("Request failed"));
render(<Notification {...broadcastPropsWithCloseUrl} />);
const closeButton = screen.getAllByRole("img")[1].parentElement;
await act(async () => {
fireEvent.click(closeButton!);
});
// 验证即使请求失败,UI也会更新
expect(screen.queryByText("重要通知内容")).not.toBeInTheDocument();
expect(request).toHaveBeenCalled();
});
it("请求期间UI应保持响应", async () => {
// 创建一个未立即resolve的Promise
let resolveRequest: any;
const promise = new Promise((resolve) => {
resolveRequest = resolve;
});
mockedRequest.mockReturnValue(promise);
render(<Notification {...broadcastPropsWithCloseUrl} />);
const closeButton = screen.getAllByRole("img")[1].parentElement;
// 第一次点击
fireEvent.click(closeButton!);
// 验证UI已立即更新
expect(screen.queryByText("重要通知内容")).not.toBeInTheDocument();
// 完成请求
await act(async () => {
resolveRequest({ data: {} });
});
});
测试执行与覆盖率
基础测试执行
在完成通知组件的测试用例编写后,可以在 package.json 中配置测试脚本:
javascript
{
"scripts": {
"test": "jest"
}
}
执行 npm run test 命令后,如下图所示,Jest 会在终端输出测试结果,包括:
- 测试文件数量
- 通过的测试用例数
- 失败的测试用例详情(包含错误堆栈信息)

覆盖率报告配置
为了更全面地评估测试质量,可以通过修改 jest.config.ts 启用覆盖率统计:
javascript
module.exports = {
collectCoverage: true, // 启用覆盖率收集
coverageDirectory: "coverage", // 指定覆盖率报告的输出目录
coverageReporters: ["text", "html", "lcov", "clover"], //指定生成的覆盖率报告格式
coverageThreshold: {
// 设置覆盖率的最低阈值,如果未达标,Jest 会报错
global: {
// 全局覆盖率要求
branches: 80,
functions: 80,
lines: 80,
statements: 80,
},
"./src/components/**/*.tsx": {
// 针对特定目录/文件设置更高要求
branches: 90,
functions: 90,
lines: 90,
statements: 90,
},
},
}
执行测试后:终端会显示各维度的覆盖率百分比,在 coverage/ 目录下生成详细报告:index.html 提供可视化分析可逐层查看未覆盖的代码路径。

示例输出中显示 common/util.ts 仅 32.39% 覆盖率,低于预设阈值。此时应该优先补充核心工具函数的测试用例。通过持续完善测试覆盖,可以有效提升组件迭代的可靠性,并为后续重构提供安全保障。
通过引入自动化测试,我们实现了从"人肉测试"到系统化保障的转变。精心设计的测试用例覆盖了各种边界情况,配合覆盖率分析,构建了多层次的质量防护体系。
如果你对前端工程化有兴趣,或者想了解更多相关的内容,欢迎查看我的其他文章,这些内容将持续更新,希望能给你带来更多的灵感和技术分享~