أشهر سبب لفقدان الثقة في مجموعة end-to-end ليس التوقيت؛ بل الحالة المشتركة. ينجح الاختبار 12 وحده ويفشل في التشغيل الكامل لأن الاختبار 7 أعاد تسمية المجموعة التي يستخدمها. أو ينجح اختبار في أيام الاثنين فقط لأن البيانات الأولية تحتوي مصروفًا لـ “هذا الأسبوع”. العزل هو العلاج، وPlaywright تعطيك معظمه مجانًا.
\nيستلم كل اختبار سياق متصفّح (browser context) خاصًّا به: ملفًّا شخصيًا يشبه وضع التصفّح الخفي، له ملفات تعريف الارتباط وlocalStorage وsessionStorage والذاكرة المؤقّتة الخاصة به. فتح سياق رخيص (أجزاء من الثانية، لا متصفّح جديد)، لذا تنشئ Playwright سياقًا جديدًا لكل اختبار. ولهذا تستطيع التشغيل مع fullyParallel: true عبر عدة عمّال (workers): فلا يستطيع اختباران رؤية تسجيلات دخول بعضهما أو المسوّدات المحفوظة.
جهة المتصفّح معزولة. أما الـ backend لديك فليس كذلك. إن عدّل اختباران المجموعة نفسها على الخادم نفسه، يتصادمان. وبقية هذا الدرس عن عزل البيانات.
\nلقد كنت تستخدم الـ fixtures أصلًا: فـ page في async ({ page }) => … واحدة منها. وتأتي Playwright أيضًا بـ context وbrowser وbrowserName وrequest (عميل HTTP يشترك في baseURL). وتعرّف fixtures خاصة بك عبر test.extend:
import { test as base, expect } from '@playwright/test';\n\ntype Group = { id: string; name: string };\n\nexport const test = base.extend<{ group: Group }>({\n group: async ({ request }, use) => {\n // Setup: create a fresh group through the API\n const response = await request.post('/api/groups', {\n data: { name: `Trip ${crypto.randomUUID().slice(0, 8)}`, members: ['Ana', 'Ben'] },\n });\n expect(response.ok()).toBeTruthy();\n const group: Group = await response.json();\n\n await use(group); // the test runs here\n\n // Teardown: runs after the test, pass or fail\n await request.delete(`/api/groups/${group.id}`);\n },\n});\n\nexport { expect };import { test, expect } from './fixtures';\n\ntest('settling up clears every balance', async ({ page, group }) => {\n await page.goto(`/groups/${group.id}`);\n // …add an expense, click Settle up…\n await expect(page.getByRole('status')).toHaveText('Everyone is settled up');\n});ثلاث خصائص تجعل هذا أفضل من beforeEach:
group في معاملاتها. والاختبارات التي لا تحتاجها لا تدفع شيئًا.await use(...)، فلا يمكن أن يخرج التنظيف عن التزامن مع التهيئة.group أن تعتمد على request؛ ويمكن لـ fixture expense أن تعتمد على group. وتحلّ Playwright الترتيب.إنشاء البيانات عبر الـ API بدل النقر في الواجهة يُبقي كل اختبار مركّزًا على مسار واحد ويوفّر ثوانيَ في كل اختبار. اختبار واحد ينقر عبر “إنشاء مجموعة”؛ والخمسون الآخرون يحصلون على مجموعة من الـ fixture.
\n\nإن كان Splitwise-lite يتطلّب تسجيل الدخول، فالتنقّل في النموذج في كل اختبار يضيّع الوقت ويُرهق خادم المصادقة. نمط Playwright هو setup project (مشروع تهيئة): اختبار واحد يسجّل الدخول ويحفظ حالة تخزين المتصفّح في ملف، والمشاريع الحقيقية تعلن اعتمادها عليه وتبدأ وقد سُجّل دخولها مسبقًا:
\n// …inside defineConfig\nprojects: [\n { name: 'setup', testMatch: /.*\\.setup\\.ts/ },\n {\n name: 'chromium',\n use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json' },\n dependencies: ['setup'],\n },\n],ينتهي اختبار التهيئة بـ await page.context().storageState({ path: 'playwright/.auth/user.json' }). أضف playwright/.auth إلى .gitignore: فهو يحتوي ملفات تعريف ارتباط لجلسات حقيقية.
بعض الحالات صعبة الإنتاج مع backend حقيقي: 500 عند الحفظ، أو استجابة بطيئة، أو مجموعة فارغة من حساب قديم. يعترض page.route الطلبات القادمة من الصفحة ويتيح لك الإجابة عنها:
test('explains a failed save', async ({ page, group }) => {\n await page.route('**/api/expenses', (route) =>\n route.fulfill({ status: 500, json: { error: 'Database unavailable' } }),\n );\n\n await page.goto(`/groups/${group.id}`);\n await page.getByLabel('Description').fill('Dinner');\n await page.getByLabel('Amount').fill('30');\n await page.getByRole('button', { name: 'Add expense' }).click();\n\n await expect(page.getByRole('alert')).toHaveText('Could not save the expense. Try again.');\n});استخدم التوجيه للنادر والمعطوب. وإن وجدت نفسك توجّه كل طلب، فقد أعدت بناء اختبار مكوّن بأداة أبطأ؛ دع المسارات السعيدة تصل إلى الـ backend الحقيقي، لأن هذا التكامل هو سبب وجود اختبارات الـ end-to-end.
\n\nويجعل العزل أيضًا تتبّع حالات الفشل أرخص. حين يفشل اختبار، تستطيع إعادة تشغيل ذلك الاختبار وحده بـ npx playwright test -g "settling up" والحصول على النتيجة نفسها، لأن لا شيء مما يعتمد عليه يعيش خارجه. أما مع الاعتماديات الخفيّة، فتنجح إعادة التشغيل المنفردة ويفشل التشغيل الكامل، وتبقى تقسّم المجموعة نصفين بعد نصفين لتجد أيّ جار كسره.
في التمرين تُكمل fixture تنشئ مجموعة وتحذفها. الدرس القادم: ماذا تفعل حين يفشل اختبار رغم كل ذلك.
\n","toc":[{"id":"sec-1","text":"سياق جديد لكل اختبار","level":2},{"id":"sec-2","text":"الـ Fixtures: التهيئة والتنظيف في مكان واحد","level":2},{"id":"sec-3","text":"تسجيل الدخول مرة واحدة","level":2},{"id":"sec-4","text":"التوجيه: التحكّم في ما يقوله الخادم","level":2}],"takeaways":["يحصل كل اختبار في Playwright على سياق متصفّح جديد (له ملفات تعريف الارتباط والتخزين والذاكرة المؤقّتة الخاصة به)، فتستطيع الاختبارات أن تعمل بالتوازي وبأي ترتيب.","الـ fixture (تجهيزة الاختبار) التي تُنشأ بـtest.extend تُعدّ شيئًا ما، وتسلّمه للاختبار عبر use()، ثم تهدمه بعد ذلك، وذلك للاختبارات التي تطلبها فقط.","يجب أن ينشئ كل اختبار البيانات التي يحتاجها (ويُفضَّل عبر الـ API) بدل الاعتماد على بيانات أولية مشتركة أو على أن اختبارًا آخر عمل قبله.","سجّل الدخول مرة واحدة في setup project، واحفظ حالة التخزين، وأعد استخدامها، بدل التنقّل في نموذج تسجيل الدخول في كل اختبار.","استخدم page.route لمحاكاة استجابات الخادم النادرة، والـ backend الحقيقي للمسارات السعيدة."],"further":[{"title":"Playwright — Fixtures","url":"https://playwright.dev/docs/test-fixtures"},{"title":"Playwright — Isolation","url":"https://playwright.dev/docs/browser-contexts"},{"title":"Playwright — Authentication","url":"https://playwright.dev/docs/auth"},{"title":"Playwright — Mock APIs","url":"https://playwright.dev/docs/mock"}],"quiz":[{"q":"ينشئ الاختبار A مجموعة اسمها “Lisbon trip”؛ ويفتح الاختبار B المجموعة “Lisbon trip” ويفحص أرصدتها. ينجح B محليًا ويفشل في CI. ما أصل المشكلة؟
","options":[{"text":"أجهزة CI أبطأ، فيحتاج B إلى مهلة أطول.","why":"السرعة ليست المشكلة؛ B يعتمد على بيانات لا توجد إلا إن عمل A أولًا، على الخادم نفسه، قبله."},{"text":"يعتمد B على بيانات A. ومع العمّال المتوازيين أو بترتيب مختلف، لا تكون المجموعة موجودة بعد حين يعمل B.","why":"صحيح. يجب أن ينشئ كل اختبار مجموعته الخاصة، مثلًا عبر fixture تستدعي الـ API وتنظّف بعد الانتهاء."},{"text":"يجب أن يستخدم B الدالةtest.describe.serial كي يعمل دائمًا بعد A.","why":"الوضع التسلسلي يجعل الاعتماد رسميًا والمجموعة أبطأ؛ ثم إن فشلًا واحدًا في A يتخطّى كل ما بعده. أزل الاعتماد بدلًا من ذلك."}],"answer":1},{"q":"في الـ fixture، ماذا يفعل الكود الواقع بعد await use(group)؟
use؛ أما السطر الذي بعده فينتظر حتى ينتهي الاختبار."},{"text":"لا شيء؛ الكود بعد use لا يُبلغ أبدًا.","why":"يُحلّ use حين ينتهي الاختبار، فيعمل الكود الذي بعده، وهكذا تنظّف الـ fixtures."},{"text":"يعمل بعد انتهاء الاختبار، حتى لو فشل الاختبار، وهذا ما يجعله مكان التنظيف.","why":"صحيح. التهيئة، ثم use(value)، ثم الهدم: دالة واحدة تملك دورة حياة المورد كلها."}],"answer":2},{"q":"ما أفضل استخدام لـ page.route في مجموعة end-to-end؟
أكمل هذه الـ fixture في Playwright كي يحصل كل اختبار يطلب group على مجموعة جديدة تُنشأ عبر الـ API، وكي تُحذف المجموعة بعد الاختبار، نجح أو فشل. ثم أكمل الاختبار كي يستلم الـ fixture ويستخدم assertion موجّهًا للويب.
test الأساسي تعيد test جديدًا موسَّعًا.","تحتاج الـ fixture إلى fixture عميل HTTP المدمجة، تلك التي يستدعي الجسم .post عليها.","سلّم القيمة للاختبار عبر المعامل الثاني لدالة الـ fixture؛ وبعد ذلك، نظّف بطريقة HTTP التي تزيل موردًا. يذكر الاختبار الـ fixture باسمها في معاملاته، ويؤكّد بـ expect الخاص بـ Playwright الذي يعيد المحاولة."],"explanation":"يعيد base.extend<{ group: Group }>({...}) كائن test جديدًا يعرف الـ fixture المسمّاة group. تطلب الـ fixture الـ fixture المدمجة request، وتنشئ مجموعة باسم فريد، وتمرّرها للاختبار عبر await use(group). وكل ما بعد use يعمل حين ينتهي الاختبار، أيًّا كانت النتيجة، فينظّف request.delete(...) حتى بعد الفشل. ويشترك الاختبار فيها بتفكيك group بجوار page؛ أما الاختبارات التي لا تذكرها فلا تنشئ مجموعة أبدًا. وأخيرًا، يعيد await expect(locator).toHaveText(...) المحاولة حتى تظهر الحالة، فلا يتسابق الاختبار مع تحميل الصفحة.