Clock 组件 Mock 时间依赖解决单元测试痛点 测试哲学

new Date() 在单元测试中不可控，因系统时钟差异导致断言失败；应抽离时间依赖为可注入的 useClock Hook，配合 fake timers 和时区隔离实现稳定测试。

为什么 new Date() 在单元测试里总不按预期走

因为真实时间不可控，每次跑测试都可能因系统时钟差异导致断言失败。比如测试“今天生成的订单号是否含当前日期”，new Date() 返回的是运行时刻，不是你写用例时想模拟的那个“今天”。

更麻烦的是，某些逻辑依赖时间差（如过期判断）、定时器（setTimeout）、或全局时间戳（Date.now()），直接 new 一个实例根本没法稳定复现。

• 不要 patch 全局 Date 构造函数——它影响整个测试环境，容易污染其他用例
• 避免在组件内部直接调用 new Date() 或 Date.now()——耦合太紧，无法注入控制点
• 优先把时间获取逻辑抽成可替换的依赖，而不是硬编码在 render 或生命周期里

React 中用 Clock 组件封装时间依赖的实操方式

所谓 Clock，不是 UI 组件，而是一个提供时间值的 React Hook 或 Context Provider。它把“当前时间”变成可注入、可 mock 的 prop 或 context 值。

典型做法是定义一个 useClock() Hook，内部默认读取 Date.now()，但允许传入 now 参数覆盖：

function useClock({ now } = {}) {  const [time, setTime] = useState(now ?? Date.now());  useEffect(() => {    if (now !== undefined) return;    const timer = setInterval(() => setTime(Date.now()), 1000);    return () => clearInterval(timer);  }, [now]);  return time;}

这样在测试中就能固定时间：

render(<MyComponent time={1717027200000} />); // 2024-05-30 00:00:00

• 生产环境不传 now，自动刷新；测试时传死值，完全可控
• 如果组件需要格式化时间（如 toLocaleDateString()），也建议把 Intl.DateTimeFormat 实例或格式化函数作为 prop 注入，避免依赖本地时区
• 注意：useEffect 中的定时器只在 now 未定义时启用，否则会跳过——这是关键隔离点

Mock setTimeout 和 setInterval 时别只 stub 不 advance

很多测试库（如 Jest）提供 jest.useFakeTimers()，但它只是冻结时间，并不自动推进。如果你写了 setTimeout(() => doX(), 5000)，不手动调用 jest.advanceTimersByTime(5000)，回调永远不会触发。

• 用 jest.useFakeTimers('modern') 替代旧版，支持 advanceTo 和更精确的微任务调度
• 对依赖轮询的组件（如倒计时、心跳检测），必须显式 advanceTimersByTime() 或 runAllTimers()，否则测试会超时或跳过逻辑
• 测试完记得 jest.useRealTimers() ——尤其在 afterEach 里，否则下一个测试可能还在 fake 模式下，行为诡异

时区和夏令时是 Clock Mock 最容易漏掉的坑

本地开发机可能是 CST，CI 环境默认 UTC，而用户浏览器又各自有本地时区。单纯 mock 时间戳（毫秒数）能绕过时区问题，但一旦涉及 toLocaleTimeString()、getHours() 这类方法，结果就不可控了。

解决方案不是禁止使用这些 API，而是统一约定时间上下文：

• 所有业务时间逻辑基于 UTC 处理（如有效期判断、日志时间戳）
• UI 层才做时区转换，且通过明确的 timeZone prop 控制，例如：<Clock timeZone="Asia/Shanghai" />
• 测试时用 Intl.DateTimeFormat 的 resolvedOptions().timeZone 断言是否生效，比直接 expect 字符串更可靠

真正难的不是怎么 mock，而是决定哪一层该信任时间、哪一层该隔离时间——Clock 的价值不在组件本身，而在帮你划清这条线。