MSW.js 与 fetch-retry 兼容性问题解析

问题背景

在使用 MSW.js 进行 API 模拟测试时，开发者可能会遇到与 fetch-retry 库的兼容性问题。具体表现为当测试用例中使用 fetch-retry 时，MSW.js 无法正确拦截请求，导致测试失败并尝试访问真实端点。

问题本质

这个问题的根源在于模块加载顺序和 fetch 函数的替换时机。MSW.js 通过拦截全局 fetch 函数来实现请求模拟，而 fetch-retry 在初始化时会缓存当前的 fetch 实现。如果在 MSW.js 初始化之前就加载了 fetch-retry，那么 fetch-retry 会缓存未被 MSW.js 修改过的原始 fetch 函数。

技术原理

1. MSW.js 的工作机制：MSW.js 通过 Service Worker 或 Node.js 的拦截器来重写全局 fetch 函数，使得所有通过 fetch 发起的请求都能被拦截并返回模拟响应。

2. fetch-retry 的实现方式：fetch-retry 是一个包装器，它在初始化时需要传入一个 fetch 实现，然后返回一个具有重试功能的新函数。

3. 模块加载顺序的影响：JavaScript 的模块系统是同步执行的，如果在模块顶层就初始化 fetch-retry，而此时 MSW.js 尚未完成初始化，就会导致 fetch-retry 缓存了错误的 fetch 实现。

解决方案

方案一：动态导入 fetch-retry

it('测试用例', async () => {
  const { default: createFetchRetry } = await import('fetch-retry');
  const fetchRetry = createFetchRetry(fetch);
  
  // 使用 fetchRetry 进行测试
});

这种方法利用了 ES 模块的动态导入特性，确保 fetch-retry 在 MSW.js 初始化完成后再加载，从而获取到正确的 fetch 实现。

方案二：封装工具函数

function createFetchRetryWrapper() {
  const fetchRetry = require('fetch-retry')(fetch);
  return fetchRetry;
}

it('测试用例', async () => {
  const fetchRetry = createFetchRetryWrapper();
  // 使用 fetchRetry 进行测试
});

通过将 fetch-retry 的初始化封装在函数中，可以延迟其执行时机，确保在调用时 MSW.js 已经完成初始化。

最佳实践建议

1. 统一初始化顺序：在测试套件中，确保所有依赖 MSW.js 拦截功能的库都在 MSW.js 初始化之后加载或使用。

2. 使用工厂模式：对于需要包装 fetch 的库，采用工厂函数模式来延迟初始化，而不是在模块顶层直接初始化。

3. 考虑测试架构：在大型项目中，可以建立一个专门的请求工具模块，集中管理所有 fetch 相关的包装和扩展，便于统一控制和维护。

总结

MSW.js 与 fetch-retry 的兼容性问题是一个典型的模块加载顺序问题。通过理解 JavaScript 模块系统和 MSW.js 的工作原理，我们可以采用动态加载或延迟初始化的策略来解决这类问题。这不仅适用于 fetch-retry，也适用于其他需要包装或扩展 fetch 功能的库。在测试架构设计中，合理控制初始化顺序和采用适当的封装模式，可以有效避免类似问题的发生。