عزل الاختبارات والتنفيذ المتوازي

لماذا يهم

الاختبارات التي يعتمد بعضها على بعض تعطي نتائج لا يثق بها أحد. ينجح اختبار في التشغيل الكامل فقط لأن اختباراً سابقاً أنشأ الطلب الذي يقرؤه، ثم يفشل حين يشغّله أحد وحده أو يضيف عاملاً؛ ويعدّل اختباران المستخدم نفسه في اللحظة نفسها فيفشل أحدهما مرة في كل عشرين تشغيلاً. حالات الفشل هذه تبدو كأنها عيوب في المنتج، وتكلّف ساعات من التحقيق، وتعلّم الفريق إعادة تشغيل البناءات الحمراء بدلاً من قراءتها. ويعدّ Martin Fowler غياب العزل سبباً شائعاً للاختبارات غير الحتمية (non-deterministic).

والسرعة هي النصف الآخر. فالحزمة التي تستغرق ساعة تُشغَّل أقل، وتصل نتائجها بعد أن ينتقل المطور إلى عمل آخر. والتنفيذ المتوازي يُبقي الحزمة المتنامية سريعة بما يكفي لتشغيلها مع كل تغيير، ولا ينجح إلا إذا كانت الاختبارات معزولة. ويساعد العزل تقرير الخطأ أيضاً: فالاختبار الذي يفشل وحده، في كل مرة، ببياناته الخاصة، هو خطوات إعادة إنتاج جاهزة للمطور.

العزل ومشكلات الحالة المشتركة

الاختبار المعزول يتحكم في حالة البداية الخاصة به: ينشئ ما يحتاجه أو يتسلّمه من تجهيزة (Fixture)، ولا يتحقق إلا من بيانات أنشأها بنفسه أو بيانات لا يغيّرها أي اختبار. وتطلب أفضل الممارسات في Playwright أن يعمل كل اختبار باستقلال، بتخزينه وملفات تعريف الارتباط (cookies) وبياناته الخاصة؛ وتعدّ Cypress اعتماد الاختبارات على حالة اختبارات سابقة نمطاً سيئاً (anti-pattern).

الحالة المشتركة (Shared State) هي أي شيء يستطيع اختبار تغييره ويستطيع اختبار آخر رؤيته. والبيانات المخصّصة للقراءة فقط، مثل كتالوج منتجات لا يعدّله أي اختبار، آمنة للمشاركة؛ أما الحالة المشتركة القابلة للتغيير فلا. والعلاج أن تعطي كل اختبار، أو كل عامل على الأقل، نسخته الخاصة مما يغيّره، وأن تبني هذه الحالة في بداية الاختبار. ويفضّل Martin Fowler إعادة بناء حالة البداية على الاعتماد على التنظيف: فحين يفشل التنظيف يفشل اختبار آخر بعيداً عن الخلل. وتختبئ الحالة المشتركة القابلة للتغيير في خمسة أماكن:

• بيانات الخادم: حساب أو سلة أو طلب أو قسيمة واحدة تستخدمها اختبارات كثيرة. يفرّغ اختبار السلة التي يفحصها اختبار آخر، وقسيمة الاستخدام الواحد لا تعمل إلا للاختبار الذي يصل إليها أولاً.
• الاعتماد على الترتيب: الاختبار B يقرأ الطلب الذي أنشأه الاختبار A. ينجح B بالترتيب المعتاد، ويفشل حين يُشغَّل وحده أو بترتيب عشوائي أو على عامل آخر.
• الحالة في الذاكرة: متغير على مستوى الوحدة البرمجية (module)، أو كائن وحيد (singleton) يتشاركه البرنامج كله، أو ذاكرة تخزين مؤقت، أو ساعة مزيّفة، أو «مستخدم حالي» يضبطه اختبار ولا يعيد ضبطه. عمليات العمّال لا تتشارك الذاكرة، لكن الاختبارات داخل العامل الواحد تتشاركها، وكذلك الخيوط (threads) المتوازية في JUnit 5.
• حالة المتصفح: ملفات تعريف الارتباط والتخزين المحلي وجلسة الدخول. وإعادة استخدام جلسة دخول محفوظة مناسبة للاختبارات التي تقرأ فقط؛ أما الاختبار الذي يسجّل الخروج أو يعدّل الملف الشخصي فيحتاج إلى جلسة خاصة به.
• موارد الجهاز والبيئة: مسار ملف ثابت مثل downloads/report.csv، أو منفذ ثابت، أو صندوق بريد مشترك واحد، أو واجهة برمجية تجريبية (sandbox) محدودة المعدّل، أو علم ميزة (feature flag) على مستوى الموقع كله.

جرّبها: مولّد عناوين بريد إلكتروني وهمية

كيف تشغّل المشغّلات الاختبارات بالتوازي

في Playwright Test وJest وpytest-xdist، العامل (worker) عملية مستقلة في نظام التشغيل تشغّل الاختبارات واحداً بعد الآخر. ومع أربعة عمّال تعمل أربعة اختبارات في اللحظة نفسها. ذاكرتها منفصلة، لكن بيئة الاختبار وقاعدة بياناتها والملفات على القرص ومنافذ الشبكة ليست كذلك. وتختلف المشغّلات فيما تقسّمه افتراضياً، وفي طريقة منح كل عامل موارده الخاصة:

• يشغّل Playwright Test ملفات الاختبار بالتوازي، وتعمل الاختبارات داخل الملف الواحد بالترتيب في العامل نفسه، إلا إذا ضبطت fullyParallel: true أو test.describe.configure({ mode: 'parallel' }). وتحدّد العدد بالخيار workers في الإعدادات أو بـ--workers. ويحصل كل اختبار على سياق متصفح (browser context) جديد، أي جلسة متصفح معزولة تشبه نافذة تصفح خاص جديدة، بملفات تعريف ارتباط وتخزين خاصة به، وبعد أي فشل يستبدل Playwright العامل بعملية جديدة.
• يحتاج pytest إلى الإضافة pytest-xdist: الأمر pytest -n 4، أو -n auto لعامل واحد لكل معالج. وتعيد التجهيزة worker_id القيم gw0 وgw1 وهكذا.
• يوزّع Jest ملفات الاختبار على عمليات عمّال، ويشغّل اختبارات الملف الواحد بالترتيب؛ والخيار --runInBand يشغّل كل شيء تسلسلياً في عملية واحدة.
• يشغّل JUnit 5 الاختبارات تسلسلياً في خيط (thread) واحد افتراضياً. والتنفيذ المتوازي اختياري: معامل الإعداد junit.jupiter.execution.parallel.enabled=true يفعّله، لكن الاختبارات تظل تعمل واحداً بعد الآخر حتى تجعلها تعمل بالتوازي فعلاً، مثلاً بـjunit.jupiter.execution.parallel.mode.default=concurrent. والاختبارات المتوازية خيوط داخل JVM واحد، لذا تتشارك الحقول الساكنة (static) والكائنات الوحيدة. ويصرّح @ResourceLock بأن الاختبارات تستخدم مورداً مشتركاً يحتاج إلى وصول متزامن.
• موارد لكل عامل: حين يتعذّر إنشاء شيء لكل اختبار، أعطِ كل عامل نسخته الخاصة. فقيمة testInfo.parallelIndex في Playwright تتراوح من ⁦0⁩ إلى عدد العمّال ناقص ⁦1⁩، فيأخذ العامل ⁦2⁩ الحساب ⁦2⁩ من مجموعة حسابات جُهّزت قبل التشغيل.
• استثناءات تسلسلية: الاختبار الذي يغيّر شيئاً عاماً، مثل نسبة ضريبة القيمة المضافة أو علم ميزة على مستوى الموقع، لا يمكن أن يعمل بجانب اختبارات أخرى. انقله إلى تشغيل منفصل صغير بالخيار --workers=1، وجدوله بحيث لا يتزامن أبداً مع التشغيل الرئيسي على البيئة نفسها، بدلاً من جعل الحزمة كلها تسلسلية.

التقسيم إلى أجزاء: توزيع الحزمة على عدة أجهزة

يتشارك العمّال معالج الجهاز الواحد وذاكرته، لذا تتوقف إضافة العمّال عن الإفادة حين ينشغل الجهاز. أما التقسيم إلى أجزاء (Sharding) فيوزّع الحزمة على عدة أجهزة: تشغّل كل مهمة CI جزءاً واحداً، أي قسماً ثابتاً من الاختبارات، ويمكن لكل جزء أن يستخدم عدة عمّال. فالأمر npx playwright test --shard=2/4 يشغّل الجزء الثاني من أربعة، ويقبل Jest وVitest الخيار --shard نفسه.

التوازن هو ما يحدد المكسب، لأن التشغيل ينتهي حين ينتهي أبطأ جزء. فمن دون fullyParallel يوزّع Playwright ملفات كاملة على الأجزاء، فقد يُبقي ملف طويل واحد جزءاً مشغولاً بينما تنتظر الأجزاء الأخرى؛ ومعه تُوزَّع الاختبارات فرادى. وكل جزء لا يُبلغ إلا عن اختباراته: يكتب Playwright تقرير blob لكل جزء، وتدمجها مهمة أخيرة في تقرير واحد قبل أن يحكم أحد على التشغيل.

وللأجزاء خطر عزل خاص بها. فهي تعمل على أجهزة مختلفة لكنها غالباً تستخدم بيئة الاختبار نفسها، وأرقام العمّال تتكرر في كل جزء. لذلك فإن اسماً مثل qa+w0@example.com، أو الحساب ⁦0⁩ من مجموعة حسابات، يستخدمه أربعة عمّال في وقت واحد؛ أضف رقم الجزء، أو استخدم قيمة عشوائية مثل UUID.

# Four CI jobs start at the same time, one shard each
npx playwright test --shard=1/4 --reporter=blob
npx playwright test --shard=2/4 --reporter=blob
npx playwright test --shard=3/4 --reporter=blob
npx playwright test --shard=4/4 --reporter=blob

# A final job downloads the four blob reports into one folder and merges them
npx playwright merge-reports --reporter html ./all-blob-reports

جرّبها: مولّد UUID

مثال تطبيقي: ثلاثة اختبارات لا تفشل إلا بالتوازي

حزمة لإتمام الشراء من ⁦120⁩ اختباراً في المتصفح تستغرق ⁦24⁩ دقيقة بعامل واحد. يضبط الفريق fullyParallel: true وأربعة عمّال، فينخفض زمن التشغيل إلى ⁦7⁩ دقائق، لكن ثلاثة اختبارات صارت تفشل في بعض التشغيلات. وما زالت الحزمة كلها تنجح في كل مرة مع --workers=1، لذا فالسبب المرجّح تداخل بين الاختبارات لا عيب في المنتج.

كل الاختبارات تسجّل الدخول بالحساب qa.shared@example.com. يضيف اختبار «إجمالي السلة» منتجين بسعر ⁦150.00⁩ و⁦80.00⁩ ويتوقع ⁦230.00⁩، لكنه يرى أحياناً ⁦0.00⁩، لأن اختبار «تفريغ السلة» الذي يعمل على عامل آخر يفرّغ السلة نفسها. ويتوقع اختبار «سجل الطلبات» أن تعرض القائمة ثلاثة طلبات، هي التي تنشئها اختبارات الطلب الثلاثة في ملفه؛ ولم ينجح إلا لأنه كان يعمل بعدها في العامل نفسه، وهو يفشل حتى حين يُشغَّل وحده. ويحفظ اختبار «تنزيل الفاتورة» الملف في downloads/invoice.pdf، حيث قد تكتب فوقه فاتورة عامل آخر.

• ينشئ كل عامل حساباً جديداً خاصاً به في تجهيزة على مستوى العامل، مع UUID في البريد الإلكتروني حتى لا تتصادم الأجزاء أيضاً.
• الاختبارات داخل العامل الواحد ما زالت تتشارك هذا الحساب واحداً بعد الآخر، لذا يفرّغ الخطاف beforeEach السلة قبل كل اختبار بدلاً من الوثوق بالاختبار السابق.
• ينشئ «سجل الطلبات» طلباته الثلاثة عبر الواجهة البرمجية (API) ويتحقق من معرّفاتها، لا من العدد الإجمالي.
• تُحفظ الفاتورة في test.info().outputPath()، وهو مجلد فريد لكل اختبار.
• يُتأكَّد من الإصلاح بالخيار --repeat-each=10 مع أربعة عمّال، لأن تشغيلاً أخضر واحداً لا يثبت الكثير.

// fixtures.ts: one fresh account per worker process
import { test as base } from '@playwright/test';
import { randomUUID } from 'node:crypto';

type Account = { id: string; email: string };

export const test = base.extend<{}, { account: Account }>({
  account: [async ({ playwright }, use) => {
    const api = await playwright.request.newContext({ baseURL: process.env.BASE_URL });
    const email = `qa+${randomUUID()}@example.com`;   // unique in every shard
    const res = await api.post('/api/test-accounts', { data: { email } });
    const account: Account = await res.json();
    await use(account);                                // shared by this worker's tests
    await api.delete(`/api/test-accounts/${account.id}`);
    await api.dispose();
  }, { scope: 'worker' }],
});

// cart.spec.ts
import { test } from './fixtures';

test.beforeEach(async ({ request, account }) => {
  await request.delete(`/api/test-accounts/${account.id}/cart`);   // start empty
});

test('download invoice', async ({ page, account }) => {
  // ...sign in as account.email and place an order...
  const downloading = page.waitForEvent('download');
  await page.getByRole('button', { name: 'Download invoice' }).click();
  await (await downloading).saveAs(test.info().outputPath('invoice.pdf'));
});

جرّبها: مولّد مستخدمين وهميين

أسئلة شائعة

المراجع

• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• Playwright DocumentationMicrosoft (Playwright)التوثيق الرسمي لـ Playwright، إطار الاختبار الشامل الذي يشغّل Chromium وWebKit وFirefox.
• Best Practices — PlaywrightMicrosoft (Playwright)اختبر السلوك الذي يراه المستخدم، واجعل الاختبارات معزولة، وفضّل المحدِّدات المتينة والتأكيدات التي تنتظر، واستخدم التتبّع لتصحيح الأخطاء.
• Best Practices — CypressCypress.ioإرشادات Cypress لاختيار العناصر بسمات مخصّصة، وتجنّب الانتظار الثابت، وإبقاء الاختبارات مستقلة.