De Fetch Mocks à MSW : un parcours de test

Le catalyseur : un refactor Axios innocent

Ça a commencé assez innocemment. "Je vais juste refactoriser ces appels de récupération pour utiliser Axios", ai-je pensé, "Qu'est-ce qui pourrait mal se passer ?" Il s'avère que beaucoup - en particulier, toutes mes simulations de récupération soigneusement conçues deviennent soudainement aussi utiles qu'une théière en chocolat.

Plutôt que de reconstruire tous mes mocks pour Axios, j'ai décidé de profiter de cette opportunité pour moderniser mon approche. Entrez Mock Service Worker (MSW).

L'ancienne méthode : plaisanter, se moquer et aller chercher

Auparavant, mes tests ressemblaient à ceci :

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

Ça a fonctionné, mais ce n'était pas vraiment élégant. Chaque test nécessitait une configuration manuelle des simulations, les simulations étaient fragiles et ne représentaient pas vraiment le comportement de mon API dans le monde réel. Je testais les détails de mise en œuvre plutôt que le comportement réel.

Entrez MSW : une meilleure façon de se moquer

Mock Service Worker (MSW) adopte une approche fondamentalement différente de la moquerie des API. Au lieu de se moquer des appels de fonction, il intercepte les requêtes réseau réelles au niveau du réseau. C'est énorme pour plusieurs raisons :

• Intégration du runtime : MSW fonctionne en interceptant les requêtes HTTP réelles, ce qui signifie que votre code s'exécute exactement comme il le ferait en production. Fini les récupérations moqueuses ou les axios : vos appels d'API réels s'exécutent inchangés.
• Conception API-First : au lieu de penser à des simulations de fonctions, vous définissez des points de terminaison d'API fictifs qui reflètent votre véritable API. Cela vous pousse vers une meilleure conception d'API et maintient vos tests alignés sur vos points de terminaison réels.
• Fidélité des requêtes/réponses : vous travaillez avec de vrais concepts HTTP - codes d'état, en-têtes, corps de réponse - au lieu d'objets fictifs simplifiés. Cela signifie que vous pouvez capturer des cas extrêmes plus réalistes.

Voici à quoi ressemblent ces mêmes tests avec 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" },
  ]);
});

Plus de configuration manuelle fictive pour chaque test : le gestionnaire MSW s'occupe de tout. De plus, ces gestionnaires peuvent être réutilisés dans de nombreux tests, réduisant ainsi la duplication et rendant vos tests plus maintenables.

La configuration

La configuration de MSW était étonnamment simple, ce qui m'a immédiatement rendu méfiant. Rien dans les tests n'est jamais aussi simple...

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

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

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

Puis créer des gestionnaires qui ressemblaient réellement à mon 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" },
    ]);
  }),
];

Le parcours de gestion des erreurs

Ma première tentative de gestion des erreurs était... eh bien, disons qu'elle était optimiste :

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

Le problème ? Le gestionnaire /trips/:id plus général capturait tout en premier. C'était comme avoir un itinéraire fourre-tout dans votre application Express avant vos itinéraires spécifiques - erreur de débutant.

Après quelques casse-tête et échecs de tests, j'ai réalisé que la meilleure approche consistait à gérer les erreurs au sein des itinéraires eux-mêmes :

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

Ce modèle est apparu : au lieu de gestionnaires d'erreurs séparés, je pouvais gérer à la fois les cas de réussite et d'erreur au même endroit, tout comme le ferait une véritable API. C'était un de ces "aha!" des moments où les tests vous poussent réellement vers une meilleure conception.

Leçons apprises

1. Mock au bon niveau : MSW vous permet de vous moquer du niveau réseau plutôt que du niveau fonction, ce qui rend les tests plus réalistes et plus robustes.
2. Pensez aux points de terminaison, pas aux fonctions : la structuration des simulations autour des points de terminaison de l'API plutôt que des appels de fonction individuels représente mieux le comportement réel de l'application.
3. Gérez les erreurs là où elles se produisent : au lieu de gestionnaires d'erreurs séparés, gérez les erreurs au sein des gestionnaires de points de terminaison eux-mêmes, comme le ferait une véritable API.

Le résultat final

La configuration finale est plus maintenable, plus réaliste et réellement utile pour détecter les vrais problèmes. Fini le temps de :

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

Au lieu de cela, j'ai des simulations d'API appropriées qui :

• Gérer les cas de réussite et d'erreur
• Utilisez des structures de réponse réalistes
• Peut être réutilisé à travers les tests
• Détecter les problèmes d'intégration

Quelle est la prochaine étape ?

Pour l'avenir, je suis enthousiasmé par :

• Simuler les erreurs réseau de manière plus réaliste
• Utilisation de l'intégration du navigateur MSW pour les tests de bout en bout
• Ajout de délais de réponse pour tester les états de chargement

Parfois, les meilleures améliorations viennent du fait d'être obligé de changer. Ce qui a commencé comme un simple refactor Axios a fini par conduire à une bien meilleure architecture de test. Et n'est-ce pas cela le refactoring ?

---

Cet article a été initialement publié sur mon blog. Suivez-moi là-bas pour plus de contenu sur le développement full-stack, les tests et la conception d'API.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!