Von Fetch Mocks zu MSW: Eine Testreise

Der Katalysator: Ein unschuldiger Axios-Refaktor

Es begann ganz harmlos. „Ich werde diese Abrufaufrufe einfach umgestalten, um Axios zu verwenden“, dachte ich, „Was könnte da schief gehen?“ Wie sich herausstellt, ziemlich viel – insbesondere alle meine sorgfältig ausgearbeiteten Apportier-Mocks, die plötzlich ungefähr so ​​nützlich sind wie eine Schokoladen-Teekanne.

Anstatt alle meine Mocks für Axios neu zu erstellen, habe ich beschlossen, diese Gelegenheit zu nutzen, um meinen Ansatz zu modernisieren. Geben Sie Mock Service Worker (MSW) ein.

Der alte Weg: Jest Mocks and Fetch

Vorher sahen meine Tests ungefähr so ​​aus:

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);
  });
});

Es hat funktioniert, war aber nicht gerade elegant. Jeder Test erforderte eine manuelle Mock-Einrichtung, die Mocks waren spröde und spiegelten nicht wirklich das Verhalten meiner API in der realen Welt wider. Ich habe Implementierungsdetails und nicht das tatsächliche Verhalten getestet.

Geben Sie MSW ein: Eine bessere Art zu verspotten

Mock Service Worker (MSW) verfolgt einen grundlegend anderen Ansatz beim API-Mocking. Anstatt Funktionsaufrufe zu verspotten, fängt es tatsächliche Netzwerkanforderungen auf Netzwerkebene ab. Das ist aus mehreren Gründen riesig:

• Laufzeitintegration: MSW funktioniert, indem es tatsächliche HTTP-Anfragen abfängt, was bedeutet, dass Ihr Code genau so ausgeführt wird, wie er es in der Produktion tun würde. Keine spöttischen Abrufe oder Axios mehr – Ihre tatsächlichen API-Aufrufe laufen unverändert.
• API-First Design: Anstatt über Funktionsmocks nachzudenken, definieren Sie Schein-API-Endpunkte, die Ihre echte API widerspiegeln. Dies treibt Sie zu einem besseren API-Design und sorgt dafür, dass Ihre Tests an Ihren tatsächlichen Endpunkten ausgerichtet sind.
• Anforderungs-/Antworttreue: Sie können mit echten HTTP-Konzepten arbeiten – Statuscodes, Header, Antworttexte – anstelle von vereinfachten Scheinobjekten. Dies bedeutet, dass Sie realistischere Randfälle erfassen können.

So sehen dieselben Tests mit MSW aus:

// 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" },
  ]);
});

Kein manuelles Schein-Setup mehr für jeden Test – der MSW-Handler kümmert sich um alles. Darüber hinaus können diese Handler für viele Tests wiederverwendet werden, wodurch Duplikate reduziert und Ihre Tests leichter wartbar werden.

Das Setup

Die Einrichtung von MSW verlief überraschend einfach, was mich sofort misstrauisch machte. Nichts beim Testen ist jemals so einfach...

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

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

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

Dann Erstellen von Handlern, die tatsächlich wie meine API aussahen:

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" },
    ]);
  }),
];

Die Reise zur Fehlerbehandlung

Mein erster Versuch zur Fehlerbehandlung war... nun, sagen wir mal, es war optimistisch:

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

Das Problem? Der allgemeinere /trips/:id-Handler fing alles zuerst ab. Es war, als hätten Sie in Ihrer Express-App vor Ihren spezifischen Routen eine Gesamtroute – Anfängerfehler.

Nach einigem Kopfschütteln und Testfehlern wurde mir klar, dass der bessere Ansatz darin besteht, Fehler innerhalb der Routen selbst zu behandeln:

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);
  });
});

Es entstand dieses Muster: Anstelle separater Fehlerhandler konnte ich sowohl Erfolgs- als auch Fehlerfälle an derselben Stelle behandeln, genau wie es eine echte API tun würde. Es war eines dieser „Aha!“ Momente, in denen Tests Sie tatsächlich zu einem besseren Design führen.

Gelernte Lektionen

1. Mock auf der richtigen Ebene: Mit MSW können Sie die Netzwerkebene statt der Funktionsebene simulieren, wodurch Tests realistischer und robuster werden.
2. Denken Sie in Endpunkten, nicht in Funktionen: Die Strukturierung von Mocks um API-Endpunkte statt einzelner Funktionsaufrufe stellt das tatsächliche Anwendungsverhalten besser dar.
3. Behandeln Sie Fehler dort, wo sie auftreten: Behandeln Sie Fehler anstelle separater Fehlerhandler innerhalb der Endpunkt-Handler selbst – genau wie es eine echte API tun würde.

Das Endergebnis

Das endgültige Setup ist wartbarer, realistischer und tatsächlich hilfreich bei der Erkennung echter Probleme. Vorbei sind die Zeiten von:

// 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" },
  ]);
});

Stattdessen habe ich richtige API-Mocks, die:

• Behandeln Sie sowohl Erfolgs- als auch Fehlerfälle
• Verwenden Sie realistische Antwortstrukturen
• Kann testübergreifend wiederverwendet werden
• Integrationsprobleme tatsächlich erkennen

Was kommt als nächstes?

Ich freue mich auf:

• Netzwerkfehler realistischer simulieren
• Verwendung der Browser-Integration von MSW für End-to-End-Tests
• Antwortverzögerungen zu Testladezuständen hinzufügen

Manchmal entstehen die besten Verbesserungen dadurch, dass man zu Veränderungen gezwungen wird. Was als einfacher Axios-Refactor begann, führte letztendlich zu einer viel besseren Testarchitektur. Und ist das nicht genau das, worum es beim Refactoring geht?

---

Dieser Artikel wurde ursprünglich auf meinem Blog veröffentlicht. Folgen Sie mir dort für weitere Inhalte zu Full-Stack-Entwicklung, Tests und API-Design.

Das obige ist der detaillierte Inhalt vonVon Fetch Mocks zu MSW: Eine Testreise. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!