الاختبار من الطرف إلى الطرف باستخدام Playwright
بضعة سيناريوهات على التطبيق الحقيقي أفضل من مئتي اختبار على نسخة مقلَّدة
اختبارات الطرف إلى الطرف باستخدام Playwright
جميع اختبارات الوحدة لديكم ناجحة، وجميع اختبارات المكوّنات ناجحة، ومع ذلك فإن مسار الشراء معطّل منذ صباح اليوم. السبب: متغيّر بيئة مفقود في بناء الإنتاج، جعل عميل الدفع يشير إلى عنوان URL فارغ. لم يكن بوسع أي اختبار في المجموعة اكتشاف ذلك، لأن أيًّا منها لم يُنفَّذ على التطبيق المبني فعليًا، والمقدَّم من الخادم الحقيقي، داخل متصفح حقيقي. كانت كل طبقة تعمل بشكل سليم؛ المشكلة كانت في تجميعها معًا.
هذا هو الدور الوحيد لاختبارات الطرف إلى الطرف، وهو ما يبرر كلفتها. فهي بطيئة، وأكثر هشاشة، ومرهقة في التشخيص، ولذلك لن تكتبوا منها مئتين. ستكتبون من خمسة إلى خمسة عشر اختبارًا، على المسارات التي يؤدي تعطّلها إلى خسارة المال أو البيانات: التسجيل، وتسجيل الدخول، والدفع، والنشر، والحذف. أما كل ما عدا ذلك فيعود إلى الطبقات الأدنى. وهذا الانضباط في الانتقاء هو ما يفصل بين مجموعة اختبارات طرف إلى طرف مفيدة تُنفَّذ عند كل دمج، ومجموعة تستغرق أربعين دقيقة ينتهي الفريق إلى تجاوزها.
التثبيت
npm init playwright@latest
ينشئ المعالج مجلد e2e وملف إعداد، ويثبّت المتصفحات. وعلى وكيل التكامل المستمر، الأمر الذي ينبغي تذكّره هو الذي يثبّت أيضًا تبعيات النظام:
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش