Rumah >hujung hadapan web >tutorial js >Daripada Fetch Mocks kepada MSW: A Testing Journey
Ia bermula dengan tidak bersalah. "Saya hanya akan memfaktorkan semula panggilan pengambilan ini untuk menggunakan Axios," saya fikir, "Apakah yang mungkin salah?" Ternyata, agak sedikit - khususnya, semua olok-olok saya yang dibuat dengan teliti tiba-tiba menjadi berguna seperti teko coklat.
Daripada membina semula semua olok-olok saya untuk Axios, saya memutuskan untuk mengambil peluang ini untuk memodenkan pendekatan saya. Masukkan Mock Service Worker (MSW).
Sebelum ini, ujian saya kelihatan seperti ini:
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); }); });
Ia berkesan, tetapi ia tidak begitu elegan. Setiap ujian memerlukan persediaan olok-olok manual, olok-olok itu rapuh, dan ia tidak benar-benar mewakili bagaimana API saya berkelakuan di dunia nyata. Saya sedang menguji butiran pelaksanaan dan bukannya gelagat sebenar.
Mock Service Worker (MSW) mengambil pendekatan yang berbeza secara asas untuk mengejek API. Daripada mengejek panggilan fungsi, ia memintas permintaan rangkaian sebenar di peringkat rangkaian. Ini besar kerana beberapa sebab:
Begini rupa ujian yang sama dengan 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" }, ]); });
Tiada lagi persediaan olok-olok manual untuk setiap ujian - pengendali MSW menguruskan semuanya. Selain itu, pengendali ini boleh digunakan semula merentas banyak ujian, mengurangkan pertindihan dan menjadikan ujian anda lebih mudah diselenggara.
Menyediakan MSW adalah sangat mudah, yang serta-merta membuatkan saya curiga. Tiada apa-apa dalam ujian yang semudah ini...
beforeAll(() => { server.listen({ onUnhandledRequest: "bypass" }); }); afterEach(() => { server.resetHandlers(); cleanup(); }); afterAll(() => { server.close(); });
Kemudian mencipta pengendali yang sebenarnya kelihatan seperti API saya:
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" }, ]); }), ];
Percubaan pertama saya dalam pengendalian ralat ialah... baiklah, katakan ia optimistik:
export const errorHandlers = [ http.get(`${BASE_URL}/trips/999`, () => { return new HttpResponse(null, { status: 404 }); }), ];
Masalahnya? Pengendali /trips/:id yang lebih umum menangkap segala-galanya terlebih dahulu. Ia seperti mempunyai laluan lengkap dalam apl Express anda sebelum laluan khusus anda - kesilapan pemula.
Selepas beberapa kegagalan menggaru kepala dan ujian, saya menyedari pendekatan yang lebih baik ialah mengendalikan ralat dalam laluan itu sendiri:
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); }); });
Corak ini muncul: bukannya pengendali ralat yang berasingan, saya boleh mengendalikan kedua-dua kes kejayaan dan ralat di tempat yang sama, sama seperti API sebenar. Ia adalah salah satu daripada "aha!" saat di mana ujian sebenarnya mendorong anda ke arah reka bentuk yang lebih baik.
Persediaan akhir lebih boleh diselenggara, lebih realistik dan sebenarnya membantu dalam menangkap isu sebenar. Sudah berlalu hari-hari:
// 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" }, ]); });
Sebaliknya, saya mempunyai olok-olok API yang betul iaitu:
Melihat ke hadapan, saya teruja tentang:
Kadangkala penambahbaikan terbaik datang daripada dipaksa untuk berubah. Apa yang bermula sebagai refactor Axios yang mudah akhirnya membawa kepada seni bina ujian yang lebih baik. Dan bukankah itu maksud pemfaktoran semula?
Artikel ini pada asalnya diterbitkan di blog saya. Ikuti saya di sana untuk mendapatkan lebih banyak kandungan tentang pembangunan tindanan penuh, ujian dan reka bentuk API.
Atas ialah kandungan terperinci Daripada Fetch Mocks kepada MSW: A Testing Journey. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!