React组件测试实战：用Mocha+Enzyme+Sinon为react-notification编写单元测试完整指南-平芜编程栈

React组件测试实战：用Mocha+Enzyme+Sinon为react-notification编写单元测试完整指南

【免费下载链接】react-notificationProvides snackbar notifications for React项目地址: https://gitcode.com/gh_mirrors/re/react-notification

本文为新手准备了一份 React 组件测试入门指南，以 React snackbar 通知组件库 react-notification 为真实案例，手把手演示如何用 Mocha + Enzyme + Sinon 三大经典工具为其编写单元测试。你会学到：如何搭建 jsdom 测试环境、如何组织共享 Mock 数据、如何用 shallow 与 mount 渲染组件、如何用 spy 验证回调与定时器行为。🔍

一、为什么选择 Mocha + Enzyme + Sinon 组合？

这套组合曾是 React 生态中最经典的测试三件套，分工非常清晰：

工具	角色	在项目中的职责
Mocha	测试运行器	提供`describe / it / before / after`结构，负责发现并执行`test/`目录下所有用例
Enzyme	组件渲染器	提供`shallow`（浅渲染）和`mount`（全量渲染），配合 chai-enzyme 做断言
Sinon	行为验证器	提供`spy`监听函数调用、`stub`替换方法，是验证回调与时序的关键
jsdom	虚拟浏览器	为 Node 环境补上`document`、`window`，让 React 组件可以渲染

💡 记忆口诀：Mocha 管"跑"，Enzyme 管"看"，Sinon 管"查"。

二、一键搭建：测试环境是如何配置的

1. 测试命令入口

打开 package.json，测试相关的脚本只有两行核心配置：

pretest脚本会先执行 ESLint 检查，保证代码风格过关后才进入测试；
test脚本调用 Mocha，通过babel-core/register让测试文件支持 ES6 与 JSX 语法，并设置 5 秒超时：

mocha --compilers js:babel-core/register --reporter spec --recursive --timeout 5000 test/setup.js test/**/*.js

注意命令中test/setup.js排在最前面——Mocha 会最先加载它，这是整个测试环境的地基。

2. 全局环境初始化：setup.js

setup.js 做了两件关键事：

创建虚拟 DOM：实例化 jsdom，把document、window、navigator挂到global上，让 React 以为自己在浏览器里运行；
注册全局工具：把React、expect（chai）、spy（Sinon）、shallow与mount（Enzyme）都提升到global，这样每个测试文件无需重复 import，直接取用即可。

这是该项目的第一个可借鉴经验：把高频依赖全局化，测试代码会干净很多。

3. 共享 Mock 数据：mockNotification.js

MockNotification.js 集中定义了一份标准的"通知对象"，包含key、message、action、dismissAfter、title、onClick以及各种样式。

这样做的好处是：几十个用例都围绕同一份数据结构编写，当组件属性变更时，只需修改一处 Mock 即可全局生效，维护成本极低。

三、Notification 组件单测：shallow 渲染实战

notification.js 是本项目最典型的单元测试文件，覆盖了 4 大类断言场景，非常适合新手模仿。

1. 渲染结构断言：className 与子元素

组件库的渲染结果相对稳定，第一件事就是验证 DOM 结构：

验证根节点是否带有notification-bar类名；
通过wrapper.find('.notification-bar-message')定位子元素，断言 message、action、title 文本是否正确渲染；
验证className、activeClassName自定义类名在setProps({ isActive: true })后是否正确切换。

这里用到的是shallow渲染：它只渲染目标组件一层，不触碰子组件内部，速度快且聚焦，适合验证组件自身的 props 透传逻辑。

2. 样式断言：验证自定义 style 生效

项目允许通过barStyle、actionStyle、activeBarStyle定制外观。测试中传入background: 'rgb(2, 2, 2)'之类的样式对象，然后用 chai-enzyme 的.to.have.style('background', 'rgb(2, 2, 2)')断言样式确实作用到了渲染结果上。

3. 事件断言：Sinon spy + simulate 点击

验证交互行为是单元测试的核心。测试中：

用spy()创建一个被调用的"探针"函数，作为onClick传入组件；
用 Enzyme 的action.simulate('click')模拟用户点击操作按钮；
断言handleClick.calledOnce为真——点击一次，回调恰好触发一次。

🎯 这是验证 React 事件处理最标准的写法：spy 负责"记录"，simulate 负责"触发"。

4. 定时器断言：dismissAfter 自动消失

Notification 组件支持dismissAfter属性：激活后倒计时结束自动触发onDismiss。这类异步行为测试用了"半程验证 + 全程验证"的成对写法：

等待dismissAfter / 2毫秒，断言onDismiss尚未触发；
等待完整时长，断言onDismiss恰好触发一次。

两条用例合在一起，才能严谨证明"计时器在正确的时间点、以正确的次数执行"。测试使用 Mocha 的done回调处理setTimeout异步，并在失败时通过done(err)把错误抛给框架。

四、NotificationStack 通知栈测试：mount 渲染实战

notificationStack.js 测试通知栈组件，这里场景更复杂，改用mount全量渲染，原因有二：

通知栈内部嵌套了StackedNotification与Notification多层组件，shallow 看不到真实行为；
部分逻辑依赖setTimeout与 CSS 过渡，必须让组件完整运行。

1. 独立消失 vs 顺序消失

dismissInOrder={false}时，栈中多条通知应各自独立消失：测试挂载两条通知，等待dismissAfter + 340ms（额外 340ms 是动画过渡的余量），断言onDismiss被调用两次。这个"+340ms 余量"的注释值得新手学习——写测试前先弄清异步来源。

2. 样式工厂函数断言

通知栈提供barStyleFactory、activeBarStyleFactory、actionStyleFactory三个工厂函数，按索引批量定制样式。测试验证了三层语义：

验证点	说明
工厂能写入新样式	断言工厂返回的`bottom`值已应用到子组件 prop
工厂尊重原有样式	断言通知自身`barStyle`的`background`不被覆盖
工厂可访问通知数据	工厂第三个参数是通知对象，测试用`notification.key`判断传入数据正确

3. 全局 onClick 与局部 onClick 的优先级

这是本项目最有业务价值的用例对：

局部：某条通知自带onClick→ 点击后局部 spy 被调用 1 次，全局 spy 调用 0 次；
全局：通知没有onClick→ 事件冒泡到栈级别，全局 spy 被调用 1 次。

用两个 spy 的 callCount 对比来锁定"事件恰好走了一条路"，比单测一侧更严密。

4. 动态更新 dismissAfter 的时序测试

测试先挂载dismissAfter={false}的通知（永不消失），确认未触发；再通过wrapper.setProps动态更新为dismissAfter={110}，断言之后会触发消失。

📌 这直接对应了 notification.js 源码中componentWillReceiveProps的分支逻辑——测试与源码逐行对应，是"测试即文档"的范例。

五、Sinon stub 的进阶用法：捕获 PropType 警告

nofitication.js 测试中还有一个巧妙技巧：React 的 PropType 校验失败只会console.error而不会抛错，普通测试根本感知不到。测试用sinon.stub(console, 'error')把警告转换成抛错，从而让"非法 title 导致崩溃"这类问题暴露出来；在after钩子里记得restore()还原，避免污染后续用例。

六、运行测试与新手常见问题

在项目根目录执行：

npm install npm test

npm test会自动先跑pretest（ESLint 检查），再执行全部 Mocha 用例，输出使用spec报告器，层次清晰。

新手常踩的坑：

忘记 setup 顺序：若不用test/setup.js先初始化 jsdom，Enzyme 渲染会报document is not defined；
异步断言过早：涉及setTimeout的用例若提前断言会误报失败，记得预留"定时器 + 过渡时间"的余量；
shallow 与 mount 混用：断言子组件内部结构必须mount；只关心目标组件自身行为用shallow更快更稳；
spy 忘记清理：Sinon 探针是局部变量时天然隔离，若挂到全局，务必在每个用例结束后恢复。