從 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中文網其他相關文章！