انتظر النتيجة وليس الساعة

يتم حفظ نموذج الإعدادات ببطء. يضيف شخص ما توقفًا مؤقتًا لمدة ثانيتين قبل التحقق من رسالة النجاح. ويمر على أجهزة الكمبيوتر المحمول الخاصة بهم. يستغرق تشغيل CI التالي وقتًا أطول قليلاً ويفشل. يقوم مطور آخر بتغيير فترة الإيقاف المؤقت إلى خمس ثوانٍ. أصبح الاختبار الآن أبطأ، ولكن السبب وراء استمراره لا يزال مفقودًا.

السؤال المفيد ليس كم ثانية تنام. وهذا ما تقوله الأدلة أن الخطوة التالية جاهزة. ينشئ هذا الدليل فحصًا صغيرًا للإعدادات المحفوظة حول هذا السؤال، باستخدام وثائق تأكيد Playwright ودليل أفضل الممارسات. لقطة الشاشة عبارة عن عرض توضيحي محلي، وليست تطبيقًا للعميل أو معيارًا للمنتج.

وقفة التخمينات. شرط يتحقق.

في العرض التوضيحي، يؤدي النقر فوق "حفظ" إلى تغيير عنصر الحالة من "حفظ" إلى "محفوظ" بعد تأخير. استعلام الرؤية الفوري يأخذ لقطة من الحاضر. ولا ينتظر دولة مستقبلية. تتحقق تأكيدات الويب الأولى لـ Playwright بشكل متكرر من محدد المواقع حتى يتم الحفاظ على الحالة المتوقعة أو انتهاء المهلة الخاصة بها.

قارن بين الطريقتين في اختبار حيث انتقلت الصفحة بالفعل إلى نموذج إعدادات التدريج الخاص بك:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

هذه مقتطفات بديلة، وليست تعليمات للنقر عليها مرتين في اختبار واحد. يمكن أن ينتهي التأكيد الثاني بمجرد ظهور "محفوظ". إذا لم يظهر مطلقًا، فسيفشل التأكيد بدلاً من الانتظار إلى أجل غير مسمى. مهلة التأكيد الافتراضية هي خمس ثوانٍ وفقًا لوثائق التأكيد الحالية؛ اختر مهلة محلية فقط عندما يبررها السلوك المتوقع لمنتجك.

الانتظار التلقائي ليس مثل انتظار النتيجة

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

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

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

يفترض المثال وجود حقل يمكن الوصول إليه باسم اسم العرض وسجل مرحلي آمن لإعادة التحميل. حدد تلك العقود في العرض التوضيحي أو في تطبيقك. لا تقم بتغيير ملف تعريف المستخدم المباشر لجعل تجربة التوقيت ملائمة.

عندما يفشل الانتظار، لا تضخمه أولاً

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

يشرح دليل قابلية التنفيذ الخاص بـ Playwright الإجراءات التي يتم انتظارها والتأكيدات التي تتم إعادة المحاولة. لا تكتسب فحوصات المساواة العامة هذا السلوك لمجرد وجود قيمة منتظرة بداخلها. تفضيل تأكيد محدد الموقع لحالة واجهة المستخدم المتغيرة؛ استخدم تأكيد الاستقصاء المحدود عندما يكون الشرط خارج هذا الشكل.

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

بطاقة مراجعة للاختبارات التي تم إنشاؤها

لكل خطوة حساسة للتوقيت، قم بتسجيل الإجراء وحالة الاستعداد وسبب المهلة والتحقق من النتيجة النهائية. في العرض التوضيحي الخاص بنا: حفظ، الحالة تساوي محفوظ، نافذة استجابة الحفظ المتفق عليها، ثم يستمر الحقل بعد إعادة التحميل. هذه البطاقة الصغيرة أسهل في المراجعة من كومة من التوقفات.

يصف AnyTest الوكلاء الذين يستكشفون تطبيق ويب وينشئون اختبارات شاملة للمراجعة البشرية. إذا بدا التدفق الذي تم إنشاؤه سريعًا جدًا أو غير موثوق به، فيجب على المراجع أن يسأل ما الذي يجعل كل انتقال جاهزًا. هذا مبدأ مراجعة، وليس ادعاءً بأن AnyTest يعرض إعدادات Playwright أو التعليمات البرمجية التي تم إنشاؤها بتنسيق معين.

يستفيد مهندس QA واحد عندما تكون قواعد المزامنة واضحة بما يكفي ليتمكن المطورون من الحفاظ عليها. يمكن للفريق الذي ليس لديه QA مخصص استخدام نفس البطاقة أثناء مراجعة الكود. الهدف هو اختبار ينتظر السبب الصحيح، ويفشل بحدود مفيدة ولا يخطئ أبدًا في التوقف مؤقتًا للإثبات.