从 Fetch Mocks 到 MSW：测试之旅

催化剂：无辜的 Axios 重构

一切的开始都很天真。 “我将重构这些 fetch 调用以使用 Axios，”我想，“可能会出现什么问题？”事实证明，相当多 - 具体来说，我所有精心制作的 fetch 模拟突然变得像巧克力茶壶一样有用。

我决定利用这个机会来现代化我的方法，而不是为 Axios 重建所有模拟。输入模拟服务人员 (MSW)。

老方法：玩笑嘲笑和获取

以前，我的测试看起来像这样：

const mockFetch = vi.fn();
global.fetch = mockFetch;

describe("API functions", () => {
  beforeEach(() => {
    mockFetch.mockReset();
  });

  test("fetchTrips - should fetch trips successfully", async () => {
    const mockTrips = [{ id: 1, name: "Trip to Paris" }];
    mockFetch.mockResolvedValueOnce({
      ok: true,
      json: async () => mockTrips,
    });

    const trips = await fetchTrips(mockSupabase);
    expect(trips).toEqual(mockTrips);
  });
});

它有效，但不够优雅。每个测试都需要手动模拟设置，模拟很脆弱，并且它们并不能真正代表我的 API 在现实世界中的行为方式。我正在测试实现细节而不是实际行为。

输入 MSW：更好的模拟方法

Mock Service Worker (MSW) 采用完全不同的 API 模拟方法。它不是模拟函数调用，而是在网络级别拦截实际的网络请求。由于以下几个原因，这是巨大的：

• 运行时集成：MSW 通过拦截实际的 HTTP 请求来工作，这意味着您的代码运行方式与生产环境中的运行方式完全相同。不再需要模拟 fetch 或 axios - 您的实际 API 调用运行不变。
• API 优先设计：您无需考虑函数模拟，而是定义反映真实 API 的模拟 API 端点。这将推动您实现更好的 API 设计，并使您的测试与实际端点保持一致。
• 请求/响应保真度：您可以使用真正的 HTTP 概念 - 状态代码、标头、响应正文 - 而不是简化的模拟对象。这意味着您可以捕获更现实的边缘情况。

以下是使用 MSW 进行相同测试的结果：

// Your API handler definition
http.get(`${BASE_URL}/trips`, () => {
  return HttpResponse.json([
    { id: "1", location: "Trip 1", days: 5, startDate: "2023-06-01" },
    { id: "2", location: "Trip 2", days: 7, startDate: "2023-07-15" },
  ]);
});

// Your test - notice how much cleaner it is
test("fetchTrips - should fetch trips successfully", async () => {
  const trips = await fetchTrips();
  expect(trips).toEqual([
    { id: "1", location: "Trip 1", days: 5, startDate: "2023-06-01" },
    { id: "2", location: "Trip 2", days: 7, startDate: "2023-07-15" },
  ]);
});

每个测试不再需要手动模拟设置 - MSW 处理程序会处理这一切。另外，这些处理程序可以在许多测试中重复使用，减少重复并使您的测试更易于维护。

设置

设置城市固体废弃物非常简单，这立即让我产生了怀疑。测试中没有什么是那么容易的......

beforeAll(() => {
  server.listen({ onUnhandledRequest: "bypass" });
});

afterEach(() => {
  server.resetHandlers();
  cleanup();
});

afterAll(() => {
  server.close();
});

然后创建实际上看起来像我的 API 的处理程序：

export const handlers = [
  http.get(`${BASE_URL}/trips`, () => {
    return HttpResponse.json([
      { id: "1", location: "Trip 1", days: 5, startDate: "2023-06-01" },
      { id: "2", location: "Trip 2", days: 7, startDate: "2023-07-15" },
    ]);
  }),
];

错误处理之旅

我第一次尝试错误处理......好吧，我们可以说它是乐观的：

export const errorHandlers = [
  http.get(`${BASE_URL}/trips/999`, () => {
    return new HttpResponse(null, { status: 404 });
  }),
];

问题？更通用的 /trips/:id 处理程序首先捕获所有内容。这就像在 Express 应用程序中在特定路线之前有一条包罗万象的路线 - 菜鸟错误。

经过一些令人头疼的测试失败后，我意识到更好的方法是处理路由本身的错误：

const mockFetch = vi.fn();
global.fetch = mockFetch;

describe("API functions", () => {
  beforeEach(() => {
    mockFetch.mockReset();
  });

  test("fetchTrips - should fetch trips successfully", async () => {
    const mockTrips = [{ id: 1, name: "Trip to Paris" }];
    mockFetch.mockResolvedValueOnce({
      ok: true,
      json: async () => mockTrips,
    });

    const trips = await fetchTrips(mockSupabase);
    expect(trips).toEqual(mockTrips);
  });
});

这种模式出现了：我可以在同一个地方处理成功和错误情况，而不是单独的错误处理程序，就像真正的 API 一样。这是“啊哈！”之一。测试实际上推动您走向更好的设计的时刻。

经验教训

1. 在正确的级别进行模拟：MSW 可以让您模拟网络级别而不是功能级别，从而使测试更加真实和稳健。
2. 思考端点，而不是函数：围绕 API 端点构建模拟，而不是单个函数调用，可以更好地代表实际的应用程序行为。
3. 在发生错误时进行处理：无需使用单独的错误处理程序，而是在端点处理程序本身内处理错误 - 就像真正的 API 一样。

最终结果

最终的设置更易于维护，更现实，并且实际上有助于捕获真正的问题。的日子已经一去不复返了：

// Your API handler definition
http.get(`${BASE_URL}/trips`, () => {
  return HttpResponse.json([
    { id: "1", location: "Trip 1", days: 5, startDate: "2023-06-01" },
    { id: "2", location: "Trip 2", days: 7, startDate: "2023-07-15" },
  ]);
});

// Your test - notice how much cleaner it is
test("fetchTrips - should fetch trips successfully", async () => {
  const trips = await fetchTrips();
  expect(trips).toEqual([
    { id: "1", location: "Trip 1", days: 5, startDate: "2023-06-01" },
    { id: "2", location: "Trip 2", days: 7, startDate: "2023-07-15" },
  ]);
});

相反，我有适当的 API 模拟：

• 处理成功和错误情况
• 使用现实的响应结构
• 可以在测试中重复使用
• 实际捕获集成问题

接下来是什么？

展望未来，我很兴奋：

• 更真实地模拟网络错误
• 使用 MSW 的浏览器集成进行端到端测试
• 添加响应延迟来测试加载状态

有时最好的改进来自被迫改变。最初的简单 Axios 重构最终导致了更好的测试架构。这不就是重构的意义吗？

---

这篇文章最初发表在我的博客上。关注我，了解更多有关全栈开发、测试和 API 设计的内容。

以上是从 Fetch Mocks 到 MSW：测试之旅的详细内容。更多信息请关注PHP中文网其他相关文章！