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

聊测试时踩过时间依赖的坑，大概每个前端都经历过。尤其当代码里出现 new Date() 或 Date.now() 时，单元测试就会变得像在赌运气——今天跑能过，明天跑可能就失败了，全看系统时钟的脸色。

问题本质在于：真实时间是全局共享的、不可控的外部状态。测试一个包含“当前时间”判断的逻辑，等于在跟一个看不见的对手博弈。解决思路其实不复杂：把时间这个依赖从代码里“抽”出来，变成可注入、可控制的东西。下面把这套做法拆开看看。

为什么 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(); // 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 控制，例如：
• 测试时用 Intl.DateTimeFormat 的 resolvedOptions().timeZone 断言是否生效，比直接 expect 字符串更可靠

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