كل ما جاء في هذا القسم حتى الآن ينطبق على React دون تغيير، لأن React Testing Library طبقة رقيقة فوق الاستعلامات نفسها وuser-event الذي تعرفه. الجزء الجديد حقًّا هو الشبكة: مكوّنات React تحبّ جلب البيانات، والطريقة التي تزيّف بها ذلك تقرّر إن كانت اختباراتك ستلتقط أخطاءً حقيقية.
\nيأخذ المكوّن ExpenseList في Splitwise-lite المصروفات كـ prop، ولديه جزء واحد من الـ state (الحالة)، وهو مرشّح البحث:
import { useState } from 'react';\nimport { formatMoney } from './money.js';\n\nexport function ExpenseList({ expenses }) {\n const [query, setQuery] = useState('');\n const visible = expenses.filter((e) =>\n e.description.toLowerCase().includes(query.trim().toLowerCase()),\n );\n\n return (\n <section aria-label=\"Expenses\">\n <label>\n Search <input value={query} onChange={(e) => setQuery(e.target.value)} />\n </label>\n {visible.length === 0 ? (\n <p>No matching expenses</p>\n ) : (\n <ul>\n {visible.map((e) => (\n <li key={e.id}>{e.description}: {formatMoney(e.amountCents)}</li>\n ))}\n </ul>\n )}\n </section>\n );\n}مع تثبيت @testing-library/react وضبط environment: 'jsdom'، تُقرأ الاختبارات مثل اختبارات الـ DOM التي كتبتها:
import { test, expect } from 'vitest';\nimport { render, screen } from '@testing-library/react';\nimport userEvent from '@testing-library/user-event';\nimport { ExpenseList } from './ExpenseList.jsx';\n\nconst expenses = [\n { id: 'e1', description: 'Dinner', amountCents: 4550 },\n { id: 'e2', description: 'Taxi', amountCents: 1800 },\n];\n\ntest('filters expenses as you type', async () => {\n const user = userEvent.setup();\n render(<ExpenseList expenses={expenses} />);\n\n await user.type(screen.getByRole('textbox', { name: 'Search' }), 'tax');\n\n const items = screen.getAllByRole('listitem');\n expect(items.map((li) => li.textContent)).toEqual(['Taxi: $18.00']);\n});\n\ntest('shows the new expense when the prop changes', () => {\n const { rerender } = render(<ExpenseList expenses={expenses} />);\n\n rerender(<ExpenseList expenses={[...expenses, { id: 'e3', description: 'Museum', amountCents: 2400 }]} />);\n\n expect(screen.getByText('Museum: $24.00')).toBeTruthy();\n});تُختبر الـ props بالـ render بقيم مختلفة (وrerender للتحديثات). ويُختبر الـ state بالتفاعل ثم فحص النتيجة؛ لا توجد طريقة لقراءة query من الاختبار، وهذه ميزة. يلفّ render التحديثات في act() الخاصة بـ React نيابةً عنك، وتزيل React Testing Library المكوّنات (unmount) بعد كل اختبار حين يكون خيار globals في Vitest مفعّلًا (وإلا فاستدعِ cleanup داخل afterEach).
المكوّن الذي يحمّل مجموعة يستدعي دالة بيانات، وهي تستدعي fetch، الذي يمرّ عبر الشبكة. تستطيع قطع هذه السلسلة عند ثلاث نقاط:
vi.mock('./load-group.js')) يتخطّى بناء الـ URL، ومعالجة رمز الحالة، وتشكيل الاستجابة. وهذه بالضبط مواضع الأخطاء.fetch (loadGroup(id, fetchImpl)) يشغّل كل كودك ولا يزيّف إلا وسيلة النقل. بسيط، وبلا مكتبة، وهو ما يستخدمه التمرين.fetch الحقيقي دون أي تغيير:import { setupServer } from 'msw/node';\nimport { http, HttpResponse } from 'msw';\n\nexport const server = setupServer(\n http.get('https://api.splitwise-lite.test/groups/:id', ({ params }) =>\n HttpResponse.json({ name: `Group ${params.id}`, members: [], expenses: [] }),\n ),\n);في ملف إعداد، استدعِ server.listen({ onUnhandledRequest: 'error' }) قبل كل الاختبارات، وserver.resetHandlers() بعد كل اختبار، وserver.close() في النهاية. ويستطيع اختبار واحد استبدال مسار ما بـ server.use(http.get(..., () => new HttpResponse(null, { status: 404 }))) ليختبر مسار الخطأ. ويمكن للمعالِجات نفسها أن تشغّل تطبيقك أثناء التطوير وفي Storybook، فيبقى الـ API المزيّف في مكان واحد.
بعض اختبارات المكوّنات تكلّف أكثر مما تلتقط. تخطّها:
\ntext-red-600، أو هل الحشوة 12px. الانتكاسات البصرية تُلتقط بشكل أفضل باختبارات لقطات الشاشة في متصفّح حقيقي، أو بمراجعة بشرية.onChange الخاص بها.expect(container).toMatchSnapshot() على مكوّن كبير يفشل مع كل تغيير غير ضارّ في البنية، ويتعلّم المراجعون الضغط على “update snapshot” دون قراءة. قد يكون snapshot صغير مضمّن لقيمة منسّقة واحدة مقبولًا؛ أما snapshot من 300 سطر فضجيج.اختبار الشبكة الجيد يفحص ما أرسلته، إضافة إلى ما فعلته بالإجابة. الـ URL الخاطئ خطأ حقيقي (/group/ بدل /groups/)، ولا يلتقطه إلا assertion على الطلب، لأن البديل المزيّف يجيب عن أي شيء بسرور. مع fetch محقون يكون ذلك expect(fetchMock).toHaveBeenCalledWith('https://api.splitwise-lite.test/groups/lisbon')؛ ومع MSW، لا يطابق المعالِج إلا المسار الصحيح، وonUnhandledRequest: 'error' يُفشل الاختبار مع أي شيء آخر.
في التمرين تختبر loadGroup مع fetch محقون يعيد كائنات Response حقيقية، وتلتقط أربعة أخطاء في الطلب وتشكيل الاستجابة. وبهذا يكتمل قسم الواجهة. بعده يأتي المتصفّح الحقيقي، حيث يلتقي أخيرًا التخطيط والتوجيه (routing) والخادم الحقيقي.
render في React Testing Library المكوّن داخل مستند jsdom؛ وتستعلم عنه وتتفاعل معه تمامًا كما تفعل مع الـ DOM العادي.","اختبر الـ props بالـ render بقيم مختلفة (أو بـ rerender)، واختبر الـ state بالتفاعل؛ ولا تمدّ يدك إلى الـ state أو الـ hooks مباشرة أبدًا.","استبدل الشبكة عند طرفها، إمّا بحقن fetch أو باعتراض الطلبات عبر MSW، كي يظلّ كود تشكيل البيانات الخاص بك يعمل في الاختبار.","أكّد الطلب الذي أرسلته (الـ URL والطريقة)، وأكّد أيضًا ما تفعله الواجهة أو الدالة بالاستجابة، بما في ذلك رموز حالة الخطأ."],"further":[{"title":"Testing Library — React Testing Library","url":"https://testing-library.com/docs/react-testing-library/intro"},{"title":"Testing Library — React Testing Library API","url":"https://testing-library.com/docs/react-testing-library/api"},{"title":"MDN — Response","url":"https://developer.mozilla.org/en-US/docs/Web/API/Response"},{"title":"Vitest — Mocking requests","url":"https://vitest.dev/guide/mocking/requests"}],"quiz":[{"q":"كيف يجب أن يتحقّق الاختبار من أن ExpenseList تُرشّح النتائج أثناء الكتابة في مربّع Search؟
query في المكوّن بعد الكتابة، وتحقّق من أنه يساوي النص المكتوب.","why":"الـ state تفصيل داخلي؛ قد يخزّن المكوّن النص الصحيح ويعرض مع ذلك القائمة الخاطئة."},{"text":"استدعِ الدالة setQuery مباشرة والتقط snapshot للنتيجة.","why":"لا تستطيع الاختبارات (ولا يجب أن تستطيع) الوصول إلى دوال ضبط الـ state في المكوّن؛ والـ snapshot لن يقول أيّ العناصر يجب أن تكون ظاهرة."}],"answer":0},{"q":"لماذا تفضّل فرق كثيرة MSW على vi.mock('./api.js') للمكوّنات التي تجلب البيانات؟
vi.mock في الملفات التي تعرض مكوّنات React.","why":"يعمل vi.mock في أي مكان؛ المشكلة في مقدار الكود الحقيقي الذي يتخطّاه."},{"text":"يعترض MSW الطلبات على مستوى الشبكة، فيظلّ الـ fetch الحقيقي وكود تشكيل البيانات لديك يعملان في الاختبار.","why":"صحيح. مع mock للوحدة، يُستبدل أي خطأ في بناء الـ URL أو تحليل الاستجابة ويختفي؛ أما مع MSW فيُختبر فعلًا."}],"answer":2},{"q":"نسيت loadGroup أن تفحص response.ok. مع استجابة 404 يكون الـ JSON هو { "error": "Not found" }، فيرمي الكود Cannot read properties of undefined. أيّ assertion يلتقط الفحص المفقود؟
await expect(loadGroup('nope', fetchMock)).rejects.toThrow()","why":"النسخة المعطوبة تُرفض أيضًا، بخطأ TypeError، فينجح أي assertion يقبل أي خطأ."},{"text":"await expect(loadGroup('nope', fetchMock)).rejects.toThrow('HTTP 404')","why":"صحيح. مطابقة الرسالة تثبت أن رمز الحالة فُحص، لا أن شيئًا آخر انفجر بالمصادفة."},{"text":"expect(fetchMock).toHaveBeenCalledTimes(1)","why":"كلتا النسختين تستدعيان fetch مرة واحدة بالضبط؛ الفرق فيما تفعلانه بالاستجابة."}],"answer":1}],"exercise":{"kind":"web","mode":"test","subject":"const API = 'https://api.splitwise-lite.test';\n\n// Loads a group: GET `${API}/groups/تطلب loadGroup(groupId, fetchImpl) العنوان https://api.splitwise-lite.test/groups/<id>، وتحوّل الـ JSON القادم من الـ API (بالدولار، وبصيغة snake_case) إلى شكل Splitwise-lite (بالسنتات، وبصيغة camelCase)، وتُرفض بالرسالة Could not load group <id> (HTTP <status>) حين لا تكون الاستجابة ok. الأشكال الدقيقة مذكورة في تعليق الـ subject.
يعطيك الكود المبدئي jsonResponse(body, status) التي تبني Response حقيقيًا، وعيّنة apiGroup. مرّر vi.fn().mockResolvedValue(jsonResponse(...)) على أنه fetchImpl وأضف اختبارات حتى تلتقط مجموعتك أربعة أخطاء مخفيّة: نسخة تتجاهل رمز حالة HTTP، ونسخة تطلب URL خاطئًا، ونسخة تنسى تحويل الدولارات إلى سنتات، ونسخة تقرأ paidBy من الحقل الخاطئ.
expect(fetchMock).toHaveBeenCalledWith('https://api.splitwise-lite.test/groups/lisbon').","قارن النتيجة كلها بـ toEqual؛ الكائن المتوقّع مكتوب بالتفصيل في تعليق الـ subject (45.5 دولارًا تساوي 4550 سنتًا).","لمسار الخطأ، استخدم jsonResponse({ error: 'Not found' }, 404) وأكّد الرسالة، لا مجرّد الرفض: فالنسخة المعطوبة تُرفض أيضًا، بخطأ TypeError."],"explanation":"لأن وسيلة النقل وحدها مزيّفة، يعمل كل سطر من loadGroup في الاختبار. يلتقط toHaveBeenCalledWith على الـ fetch mock الـ URL الخاطئ، الذي لا يراه أي assertion على النتيجة، لأن البديل المزيّف يجيب عن أي URL. وtoEqual واحد على المجموعة المحوّلة يلتقط خطأي التشكيل معًا: الدولارات التي بقيت 45.5، وpaidBy الذي يعود undefined. اختبار 404 هو الدقيق: بدون فحص ok، يظلّ الكود يُرفض، بالرسالة Cannot read properties of undefined، فلا يثبت أن رمز الحالة عولج عن قصد إلا مطابقة الرسالة HTTP 404. وهذا هو الانضباط نفسه الذي يمنحك إياه MSW، دون المكتبة.