使用Jest+React测试时，如何为每个用例重置fetch-mock？

嘿，这个场景我太熟悉了——每次手动重置fetch-mock确实有点繁琐，给你几个更优雅的优化方案，能让你的测试代码更干净、更易维护：

1. 用Jest生命周期钩子自动重置mock #

这是我最常用的方案，通过beforeEach和afterEach钩子，给每个测试用例设置默认的正确响应，测试结束后自动重置mock，从根源上避免手动恢复的麻烦：

// 假设CORRECTRESPONSE和ERRORRESPONSE已经定义
beforeEach(() => {
  // 每个测试开始前，默认设置正确响应
  fetchMock.get('/api/your-endpoint', CORRECTRESPONSE);
});

afterEach(() => {
  // 每个测试结束后，重置fetch-mock到初始状态
  fetchMock.reset(); 
  // 如果是fetch-mock的旧版本，可能需要用fetchMock.restore()
});

test('正常请求：获取正确数据', async () => {
  const result = await yourFetchFunction();
  expect(result).toEqual(CORRECTRESPONSE);
});

test('错误请求：处理错误响应', async () => {
  // 仅在当前测试中覆盖mock，返回错误数据
  fetchMock.get('/api/your-endpoint', { status: 500, body: ERRORRESPONSE });
  const result = await yourFetchFunction();
  expect(result).toEqual(ERRORRESPONSE);
});

优点：每个测试用例完全独立，不用手动写恢复代码，重复逻辑被钩子统一处理，代码更简洁。

2. 使用fetch-mock的mockOnce临时覆盖 #

如果只是需要某一次请求返回错误，之后自动回到默认响应，可以用mockOnce方法——它只会让这个mock生效一次，非常适合单测试用例里有多次请求的场景：

// 全局设置默认的正确响应
fetchMock.get('/api/your-endpoint', CORRECTRESPONSE);

test('先处理错误，再恢复正常请求', async () => {
  // 第一次请求返回错误
  fetchMock.mockOnce('/api/your-endpoint', { status: 500, body: ERRORRESPONSE });
  const errorResult = await yourFetchFunction();
  expect(errorResult).toEqual(ERRORRESPONSE);

  // 第二次请求自动回到默认的正确响应
  const normalResult = await yourFetchFunction();
  expect(normalResult).toEqual(CORRECTRESPONSE);
});

优点：不需要手动重置mock，临时覆盖的逻辑非常清晰，适合需要模拟“先错后对”的场景。

3. 用原生Jest mock函数动态控制 #

如果不想依赖fetch-mock，也可以直接用Jest的原生mock来模拟fetch，灵活性更高：

// 在测试文件顶部mock全局fetch
global.fetch = jest.fn();

afterEach(() => {
  // 清除所有mock的调用记录和返回值
  jest.clearAllMocks();
});

test('正常请求场景', async () => {
  // 设置fetch返回正确响应
  fetch.mockResolvedValue({
    ok: true,
    json: () => Promise.resolve(CORRECTRESPONSE)
  });
  const result = await yourFetchFunction();
  expect(result).toEqual(CORRECTRESPONSE);
});

test('错误请求场景', async () => {
  // 设置fetch返回错误响应
  fetch.mockResolvedValue({
    ok: false,
    json: () => Promise.resolve(ERRORRESPONSE)
  });
  const result = await yourFetchFunction();
  expect(result).toEqual(ERRORRESPONSE);
});

优点：完全使用Jest原生能力，不用额外依赖fetch-mock，对于复杂的mock逻辑控制更灵活。

4. 按场景隔离测试（用describe块） #

如果你的测试用例很多，可以把正常场景和错误场景分到不同的describe块里，每个块单独设置mock，逻辑更清晰：

describe('正常请求场景', () => {
  beforeEach(() => {
    fetchMock.get('/api/your-endpoint', CORRECTRESPONSE);
  });

  afterEach(() => {
    fetchMock.reset();
  });

  test('获取列表数据', async () => { /* ...测试逻辑 */ });
  test('验证数据格式', async () => { /* ...测试逻辑 */ });
});

describe('错误请求场景', () => {
  beforeEach(() => {
    fetchMock.get('/api/your-endpoint', { status: 500, body: ERRORRESPONSE });
  });

  afterEach(() => {
    fetchMock.reset();
  });

  test('显示错误提示', async () => { /* ...测试逻辑 */ });
  test('处理空数据', async () => { /* ...测试逻辑 */ });
});

优点：同一场景的测试共享mock设置，不用在每个测试里重复覆盖，代码结构更规整。

总的来说，第一种用Jest生命周期钩子的方案是最通用的，能最大限度保证测试的独立性，减少重复代码，也不容易出错。

内容的提问来源于stack exchange，提问作者justHelloWorld