الانتظار والتزامن

لماذا يهم

التوقيت سبب شائع لتذبذب اختبارات الواجهة: اختبار ينجح على حاسوب سريع ويفشل على خادم CI مزدحم، أو يفشل مرة في كل عشرين تشغيلاً. وكل فشل زائف يكلّف أحداً وقتاً في التحقيق، والفريق الذي يرى كثيراً منه يبدأ بإعادة تشغيل البناءات الحمراء بدلاً من قراءتها. وهكذا يمرّ عيب حقيقي دون أن ينتبه إليه أحد.

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

توقيت الاختبار وتوقيت التطبيق

يعمل الاختبار والتطبيق على ساعتين مختلفتين. فالأمر مثل النقر يعود بمجرد أن ينفّذه المتصفح، وينتقل الاختبار إلى سطره التالي. أما ما بدأه النقر فينتهي لاحقاً وفق جدول التطبيق: فكما رأيت في درس «أساسيات JavaScript للمختبِرين»، تعيد fetch() وعداً معلّقاً (Pending promise)، ولا تتغير الصفحة إلا عند وصول الاستجابة.

ولكي يتزامن الاختبار يحتاج إلى شرط يستطيع فحصه: شيء في الصفحة أو في عنوان URL أو في الشبكة لا يصبح صحيحاً إلا عندما يكون التطبيق جاهزاً للخطوة التالية. ومن التأخيرات المعتادة التي يجب التخطيط لها:

• طلبات الشبكة: التحميل والحفظ والبحث تنتهي عندما يردّ الخادم.
• العرض: قائمة أو إجمالي يظهر بعد وصول بياناته، وأحياناً على مرحلتين (عنصر نائب أولاً، ثم القيم).
• الحركات المرئية (Animations): نافذة حوار تنزلق إلى مكانها، أو زر يتحرك ريثما يستقر تخطيط الصفحة.
• المؤقتات: مربع بحث ينتظر ⁦300⁩ ملّي ثانية بعد آخر ضغطة مفتاح (Debounce)، أو رسالة تختفي بعد ⁦5⁩ ثوانٍ.
• التنقل: إعادة توجيه بعد تسجيل الدخول، أو تبويب جديد، أو تنزيل ملف.

لماذا لا يكون الانتظار الثابت حلاً أبداً

أسرع طريقة لجعل اختبار مستعجل ينجح هي إضافة توقف: Thread.sleep(3000) أو time.sleep(3) أو cy.wait(3000) أو page.waitForTimeout(3000). لكن الانتظار الثابت لا يعرف ما الذي ينتظره؛ فهو ينتظر مدة محددة ثم يتابع، سواء كان التطبيق جاهزاً أم لا. ويصف توثيق Playwright الاختبارات التي تنتظر الوقت بأنها متذبذبة بطبيعتها، وتعدّ أفضل ممارسات Cypress انتظار مدد اعتباطية نمطاً خاطئاً (Anti-pattern).

ويمكنك مشاهدة المشكلة مع نقطة نهاية بطيئة: فأداة «محاكي رموز حالة API» تردّ بعد تأخير تختاره، حتى ⁦10⁩ ثوانٍ. ويخطئ الانتظار الثابت بثلاث طرق:

• أقصر من اللازم في التشغيل البطيء: على خادم CI مزدحم تصل استجابة الدفع بعد ⁦3.4⁩ ثانية، فيقرأ الاختبار عند ⁦3.0⁩ ويفشل، لكن في بعض التشغيلات فقط، فيصبح الاختبار متذبذباً.
• أطول من اللازم في التشغيل السريع: إذا استغرقت الاستجابة ⁦0.3⁩ ثانية ينتظر الاختبار ⁦3⁩ ثوانٍ مع ذلك. ومئتا اختبار في كل منها انتظار كهذا تقضي مجتمعةً ⁦10⁩ دقائق في كل تشغيل دون أن تفعل شيئاً.
• بلا قصد واضح: sleep(3000) لا تقول ما الذي كان الكاتب ينتظره، فلا القارئ التالي ولا رسالة الفشل يعرفان أيّ شرط كان مهماً.

جرّبها: محاكي رموز حالة API

الانتظار الضمني والانتظار الصريح

لكل انتظار قائم على شرط ثلاثة أجزاء: الشرط نفسه، ومهلة تنهي الانتظار بخطأ، وفترة استطلاع (Polling interval) تحدد مدى تكرار فحص الشرط. ويوفّر Selenium WebDriver نوعين من الانتظار.

الانتظار الضمني (Implicit wait) إعداد واحد على مستوى الجلسة: كل بحث عن عنصر يعيد المحاولة حتى يصبح العنصر موجوداً في DOM أو تنتهي المهلة (والقيمة الافتراضية ⁦0⁩، أي الفشل فوراً). وهو ينتظر الوجود فقط، والعنصر قد يكون موجوداً لكنه مخفي أو معطّل أو مغطّى. كما يبطئ عمليات البحث التي يُفترض ألا تجد شيئاً: فالتحقق باستخدام findElements من غياب رسالة خطأ يكلّف المهلة الضمنية كاملة.

أما الانتظار الصريح (Explicit wait) فيُكتب عند الخطوة التي تحتاجه: كائن WebDriverWait بمهلة وشرط. وتوفّر ExpectedConditions (وexpected_conditions في Python) الشروط الشائعة، مثل: ظاهر، وقابل للنقر، وغير ظاهر، والنص موجود، وعنوان URL يحتوي على قيمة، ويمكنك تمرير دالتك الخاصة: d -> … في Java أو lambda d: … في Python، وهي الفكرة نفسها التي تقوم عليها الدالة السهمية (Arrow function) في JavaScript، وd هو المشغّل (Driver). ويفحص WebDriverWait الشرط افتراضياً كل ⁦500⁩ ملّي ثانية ويعود بمجرد تحققه. ويحذّر توثيق Selenium من الخلط بين الانتظار الضمني والصريح: فالمهلتان تتداخلان، وقد تفشل الخطوة بعد وقت أطول مما توحي به أيٌّ من القيمتين.

// A) Implicit wait: one session-wide setting, used by every findElement call.
//    It waits until the element is present in the DOM, not visible or clickable.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(5));

// B) Explicit wait: a condition at the step that needs it. Use B instead of A,
//    never both in the same session.
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.textToBePresentInElementLocated(
    By.cssSelector("[data-testid=payment-status]"), "Paid"));
wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("[data-testid=download-receipt]"))).click();

// Your own condition: a function the wait calls until it returns true
wait.until(d -> d.findElements(By.cssSelector("[data-testid=result-row]")).size() == 1);

الانتظار التلقائي في Playwright وCypress

يُجري Playwright فحوص القابلية للتفاعل (Actionability) قبل كل إجراء. ففي click() يجب أن يكون العنصر ظاهراً، ومستقراً (لا يتحرك)، وقادراً على استقبال الأحداث (لا يغطيه عنصر آخر)، ومفعّلاً؛ وفي fill() يجب أن يكون ظاهراً ومفعّلاً وقابلاً للتحرير. وتتكرر الفحوص حتى تنجح أو تنتهي المهلة. والتأكيدات التي تعيد المحاولة، من درس التأكيدات، تنتظر الحالة المتوقعة بالطريقة نفسها. ويبحث المحدِّد (Locator) عن عنصره من جديد عند كل استخدام، فلا يترك عنصرٌ أُعيد عرضه الاختبارَ ممسكاً بمرجع قديم، وهو الاستثناء StaleElementReferenceException المعروف لمستخدمي Selenium.

ويعيد Cypress محاولة الاستعلامات مثل cy.get() وcy.contains() مع التأكيد المرتبط بها، مدة ⁦4⁩ ثوانٍ افتراضياً، وينتظر أن يصبح العنصر قابلاً للتفاعل قبل .click() أو .type(). ولانتظار الخادم أعطِ الطلب اسماً مستعاراً (Alias) باستخدام cy.intercept() وانتظر هذا الاسم، لا رقماً أبداً.

الانتظار التلقائي يتحقق من أن العنصر قابل للاستخدام، لا من أن التطبيق جاهز. فقد يكون زر «Pay now» مفعّلاً قبل تحميل إجمالي الطلب، وسينقره Playwright. وإذا كانت الخطوة تعتمد على بيانات فتحقّق من تلك البيانات أولاً. ولانتظار استجابة ابدأ الاستماع قبل الإجراء الذي يرسل الطلب، وإلا فقد تصل استجابة سريعة قبل أن يبدأ الانتظار. كما ينصح توثيق Playwright بعدم انتظار حالة networkidle في الاختبارات.

// Playwright: click() waits until the button is visible, stable, receives
// events and is enabled; toHaveText() retries until it matches (5 s default).
await page.getByRole('button', { name: 'Pay now' }).click();
await expect(page.getByTestId('payment-status')).toHaveText('Paid');

// Playwright: to wait for the server, start listening before the click.
const response = page.waitForResponse('**/api/payments');
await page.getByRole('button', { name: 'Pay now' }).click();
expect((await response).status()).toBe(201);

// Cypress: queries retry with their assertion (4 s default);
// an intercept alias waits for the request instead of a number.
cy.intercept('POST', '/api/payments').as('pay');
cy.contains('button', 'Pay now').click();
cy.wait('@pay');
cy.get('[data-testid=payment-status]').should('have.text', 'Paid');

مثال تطبيقي: إصلاح اختبار دفع متذبذب

اختبار Playwright لصفحة الدفع يفشل في نحو تشغيل واحد من كل عشرة تشغيلات لخط الأنابيب (Pipeline) بالرسالة Expected: "Paid", Received: "Processing"، أما على حاسوب كاتبه فينجح دائماً. ويُظهر الأثر (Trace) أن قراءة الحالة حدثت بعد ⁦3.0⁩ ثانية من النقر وأن استجابة الدفع وصلت عند ⁦3.4⁩. كما تحمّل الصفحة إجمالي الطلب بعد تحميل الصفحة نفسها، وهذا ما كان الانتظار الثابت الأول يغطيه.

يستبدل الإصلاح كل انتظار ثابت بالشرط الذي كان يخمّنه. وقد قاس الفريق خطوة الدفع على بيئة Staging المشتركة: أقل من ثانية في العادة، ونحو ⁦8⁩ ثوانٍ في أسوأ الحالات. وهذا القياس هو ما يحدد المهلة الأطول الوحيدة. ولنقطة نهاية متاحة للعموم تعطيك أداة «محلّل زمن الاستجابة» بيانات من النوع نفسه: الوسيط والحد الأقصى وp95 (الزمن الذي بقيت ضمنه ⁦95%⁩ من العيّنات) عبر عدة عيّنات.

• ⁦[1]⁩ يصبح الانتظار الثابت الأول تأكيداً على الإجمالي الظاهر، ⁦172.50⁩ ريالاً (172.50 SAR). فهو يقول ما المقصود بـ«تم التحميل»، ويكشف أيضاً أي إجمالي خاطئ.
• ⁦[2]⁩ و⁦[3]⁩ يصبحان تأكيداً واحداً يعيد المحاولة. في التشغيل العادي يتابع خلال ثانية من النقر، ولا يُسمح بانتظار يصل إلى ⁦15⁩ ثانية إلا لهذه الخطوة، والتعليق يسجّل السبب.
• النقرة الأخيرة لا تحتاج إلى انتظار خاص بها: فـPlaywright ينتظر حتى يصبح زر «Download receipt» مفعّلاً.
• وإذا احتاج الدفع لاحقاً إلى أكثر من ⁦15⁩ ثانية، فأبلغ عن ذلك بوصفه مشكلة أداء مع التوقيتات، بدلاً من رفع المهلة مرة أخرى.

// BEFORE: always passes locally, fails in about one CI run in ten
await page.goto('/orders/1042/pay');
await page.waitForTimeout(2000);                    // [1] "let the total load"
await page.getByRole('button', { name: 'Pay now' }).click();
await page.waitForTimeout(3000);                    // [2] "let the payment finish"
const status = await page.getByTestId('payment-status').textContent();
expect(status).toBe('Paid');                        // [3] reads once
await page.getByRole('button', { name: 'Download receipt' }).click();

// AFTER: each sleep replaced by the condition it was guessing at
await page.goto('/orders/1042/pay');
await expect(page.getByTestId('order-total')).toHaveText('172.50 SAR');       // [1]
await page.getByRole('button', { name: 'Pay now' }).click();
// [2] + [3]: payment sandbox measured at up to 8 s on shared staging
await expect(page.getByTestId('payment-status'))
  .toHaveText('Paid', { timeout: 15_000 });
await page.getByRole('button', { name: 'Download receipt' }).click();   // auto-waits

جرّبها: محلّل زمن الاستجابة

أسئلة شائعة

المراجع

• Waiting Strategies — SeleniumSelenium Projectلماذا تتسابق اختبارات المتصفح مع الصفحة، وكيف تزامن الانتظارات الضمنية والصريحة سكربت WebDriver مع التطبيق.
• Auto-waiting — PlaywrightMicrosoft (Playwright)فحوص الجاهزية التي يجريها Playwright قبل كل إجراء — مرئي، ومستقر، ومفعّل، ويستقبل الأحداث — والتي تُغني عن معظم الانتظارات المكتوبة يدوياً.
• Best Practices — CypressCypress.ioإرشادات Cypress لاختيار العناصر بسمات مخصّصة، وتجنّب الانتظار الثابت، وإبقاء الاختبارات مستقلة.
• WebDriver (W3C)W3C · 2026بروتوكول W3C الذي تنفّذه المتصفحات لتتحكم فيها أدوات الأتمتة مثل Selenium عن بُعد (الإصدار Level 2 مسودة عمل).