应使用 mock-websocket 模拟连接，隔离网络依赖，聚焦验证自身逻辑：消息响应、发送条件、异常兜底；配合 jest/vitest 异步断言，检查业务结果而非协议细节。
直接用真实 WebSocket 连接做单元测试，既慢又不可靠——网络波动、服务不可用、消息时序难控。真正高效的做法是隔离依赖，模拟连接行为，聚焦验证你自己的逻辑是否正确响应“收到消息”“发送成功”“连接断开”等事件。
用 Mock-WebSocket 替代真实连接
安装轻量级模拟库，它不启动真实服务，只在内存中复现 WebSocket API 行为：
- 运行
npm install mock-socket（无 peer 依赖，TypeScript 类型开箱即用） - 在测试文件中导入：
import { WebSocket, Server } from 'mock-socket' - 把原代码里
new WebSocket(url)的调用保留不动，但让url指向一个本地 mock 地址（如'ws://localhost:3001'） - 在测试前启动一个
Server实例监听该地址，并定义它如何响应消息、何时触发close等
验证异步逻辑的三个关键点
你的模块往往要处理“发完等回执”“收多条按顺序处理”“超时自动重试”这类流程。测试时重点覆盖：
OpenGemini Next.js Bestpractice Builder
下载
使用固定的 Next.js/Tailwind/Prisma 技术栈构建并记录独立 SaaS 项目，仅将 FastAPI 用于 Python 工作负载，并遵循严格的架构规范。
-
消息接收是否触发预期回调：给 mock socket 发一条字符串，检查你模块内部的
onmessage处理函数是否被调用，参数是否匹配 -
发送动作是否按条件执行：比如用户输入后调用
sendMessage()，检查 mock connection 的send方法是否被调用，传入内容是否含时间戳或格式化字段 -
异常路径是否兜底：手动触发
socket.close()或socket.onerror，确认你的重连逻辑、错误提示、状态重置都如期发生
配合 Jest 或 Vitest 写断言更稳
利用测试框架的异步工具，避免“还没收到就断言失败”：
- 用
await waitFor(() => expect(...).toBe(...))等待异步副作用完成（Vitest） - Jest 中可用
jest.useFakeTimers()快进超时逻辑，不用真等 5 秒 - 对每个测试用例单独创建新
Server和WebSocket实例，避免状态污染 - 断言时优先检查业务结果（如“消息列表长度加 1”），而非只看 console.log
不需要测协议细节，只测你的代码
Mock-WebSocket 已确保 send 调用会走通、onopen 会在握手后触发。你不必验证“HTTP 101 状态码是否返回”，而应专注：
- 收到
{type: 'chat', text: 'hi'}后，是否调用了渲染函数？ - 连续调用两次
send()，是否生成了两个带不同 id 的消息对象？ - 网络中断后，重连计数器是否从 0 变成 1？
