حاكي التبعية. حدد الحدود.

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

يستخدم هذا الدليل شاشة صغيرة لعرض أسعار التسليم لإظهار كيفية محاكاة التبعية وتصنيف الأدلة بأمانة. يعتمد على [دليل المحاكاة الساخرة Playwright] (تبعية https://playwright.dev/docs/simulated) ووثائق الشبكة. الشاشة المعروضة هنا عبارة عن عرض توضيحي محلي يحتوي على خيارات شحن مخترعة، وليس سير عمل العميل أو الخدمة المباشرة.

قرر السؤال الذي يجيب عليه الاختبار

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

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

قم بتثبيت المسار قبل حدوث الطلب

في هذا التطبيق التوضيحي، تحميل صفحة طلبات الأسعار /api/delivery-quote. يعترض المثال هذا المسار الدقيق ويعيد كائن JSON متحكمًا فيه. قم بتسجيل المعالج قبل التنقل حتى لا يتمكن الطلب الأول من الهروب من الإعداد المقصود.

await page.route('**/api/delivery-quote', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ label: 'Standard', price: '4.00' })
  });
});
await page.goto('/delivery-quote');
await expect(page.getByRole('status')).toHaveText('Standard: 4.00');

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

يميز Route API الخاص بـ Playwright بين تلبية الطلب وجلب استجابة حقيقية وتعديلها. المثال أعلاه لا يستدعي خدمة عرض الأسعار الأولية. سيكون لمثال Route.fetch() حدود مختلفة لأنه لا يزال يعتمد على الاستجابة الأولية.

حالات فشل الاختبار دون انتظار انقطاع الخدمة لدى البائع

قم بإرجاع استجابة 503 في اختبار ثانٍ، ثم تحقق من أن الصفحة توضح أن عرض الأسعار غير متاح وتقدم الإجراء التالي المقصود. يمكن أن يُرجع الاختبار الثالث نتيجة فارغة ناجحة إذا كانت هذه حالة ذات معنى في عقدك. اجعل كل إعداد صغيرًا وصريحًا.

await page.route('**/api/delivery-quote', route =>
  route.fulfill({ status: 503, body: 'Unavailable' })
);
await page.goto('/delivery-quote');
await expect(page.getByRole('alert')).toHaveText('Quote unavailable');

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

انتبه إلى النقاط العمياء

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

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

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

أعط الدليل اسمًا يبقى موجودًا في لوحة المعلومات

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

يصف AnyTest الاستكشاف الذي يعتمد على عنوان URL والاختبارات التي يراجعها البشر. قم بتطبيق نفس سؤال الدليل على أي تدفق مقترح: ما هي التبعيات الحقيقية، والتي تم التحكم فيها، وما الذي يحدده التمرير؟ لا يطالب هذا الدليل بواجهة وهمية محددة داخل AnyTest.

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