Ç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).
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.
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 :
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 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" }, ]); }), ];
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.
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 :
Pour l'avenir, je suis enthousiasmé par :
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!