ما يجب مراعاته عند كتابة اختبارات E2E # frontend @ twiliosendgrid

في Twilio SendGrid ، نكتب اختبارات شاملة (E2E) في نهاية ميزة جديدة أو دورة تطوير الصفحة لضمان توصيل جميع الأجزاء وتعمل بشكل صحيح بين الواجهة الأمامية والخلفية من منظور المستخدم النهائي.

لقد جربنا العديد من أطر عمل الاختبار والمكتبات الخاصة بـ E2E ، مثل إطار عمل Ruby Selenium المخصص داخل الشركة ، و WebdriverIO ، وبشكل أساسي ، Cypress لأكثر من عامين كما هو موضح في الجزء الأول والجزء الثاني من سلسلة منشورات المدونة التي توثق ترحيلنا عبر الكل الحلول. بغض النظر عن إطار العمل أو المكتبة التي استخدمناها ، وجدنا أنفسنا نطرح نفس الأسئلة حول الميزات التي يمكننا أتمتة وكتابة اختبارات E2E لها. بعد تحديد الميزات التي يمكننا اختبارها ، لاحظنا أيضًا أننا نطبق نفس الاستراتيجية العامة مرارًا وتكرارًا لكتابة الاختبارات وإعدادها.

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

أسئلة يجب طرحها إذا كان بإمكانك أتمتة اختبار E2E

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

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

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

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

4. هل يمكننا تحديد العناصر التي نحتاج إلى التفاعل معها في الصفحة؟ هل تتعامل مع إطارات مضمنة أو عناصر لا تتحكم فيها ولا يمكنك تغييرها؟ للتفاعل مع العناصر الموجودة على الصفحة ، يمكنك إضافة محددات أكثر تحديدًا مثل سمات "ربط البيانات" أو سمات "اختبار البيانات" بدلاً من التحديد على المعرفات أو أسماء الفئات. تكون المعرفات وأسماء الفئات أكثر عرضة للتغيير لأنها مرتبطة بشكل شائع بالأنماط. تخيل محاولة تحديد أسماء أو معرفات فئة مجزأة من مكونات نمطية أو وحدات CSS خلاف ذلك. بالنسبة للعناصر المُنشأة من قِبل جهة خارجية أو مكتبات المكونات مفتوحة المصدر مثل تحديد التفاعل ، يمكنك التفاف هذه العناصر بعنصر أصل بسمة "ربط البيانات" وتحديد العناصر الفرعية الموجودة تحتها. للتعامل مع إطارات iframe ، أنشأنا أوامر مخصصة لاستخراج عناصر DOM التي نحتاج إلى تأكيدها والعمل وفقًا لها ، وسنقدم مثالاً لاحقًا.

هناك المزيد من الاعتبارات التي يجب أخذها في الاعتبار ، ولكن كل ذلك يتلخص في سؤال واحد: هل يمكننا تكرار اختبار E2E هذا بطريقة متسقة وفي الوقت المناسب وتحقيق نفس النتائج؟

الإستراتيجية العامة لكتابة اختبارات E2E

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

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

من المهم التفكير: كيف يمكنني إعادة تعيين بيانات هذا المستخدم إلى نقطة البداية حتى أتمكن من اختبار الجزء من الميزة التي أريدها فقط؟

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

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

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

5. ترجم خطوات المستخدم التي سجلتها في اختبارات Cypress مع المساعدين الذين قمت بإنشائهم. في الاختبارات ، نقوم عادة بتسجيل الدخول إلى مستخدم من خلال واجهة برمجة التطبيقات (API) ونحتفظ بملف تعريف ارتباط الجلسة قبل تشغيل كل حالة اختبار للبقاء مسجلاً الدخول. ثم نقوم بإعداد بيانات المستخدم أو هدمها من خلال واجهة برمجة التطبيقات للحصول على نقطة بداية متسقة. مع كل شيء في مكانه ، نزور الصفحة التي سنختبرها مباشرة لميزتنا. نواصل تنفيذ خطوات التدفق مثل تدفق الإنشاء أو التحديث أو الحذف ، مع التأكيد على ما يجب أن يحدث أو يكون مرئيًا على الصفحة على طول الطريق. من أجل تسريع الاختبارات وتقليل التقلبات ، تجنب إعادة التعيين أو إنشاء الحالة من خلال واجهة المستخدم وتجاوز أشياء مثل تسجيل الدخول من خلال صفحة تسجيل الدخول أو حذف الأشياء من خلال واجهة المستخدم للتركيز على الأجزاء التي تريد اختبارها. تأكد دائمًا من عمل تلك الأجزاء في الخطافات "قبل" أو "قبل كل". وإلا ، إذا استخدمت خطافات "بعد" أو "بعد كل" ، فقد تفشل الاختبارات بينهما ، مما يؤدي إلى عدم تشغيل خطوات التنظيف مطلقًا والتسبب في فشل عمليات التشغيل الاختبارية اللاحقة.

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

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

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

فيما يلي نموذج تخطيط معياري لاختبار Cypress حيث أنشأنا أمر دعم عالمي لتسجيل الدخول يسمى "cy.login (اسم المستخدم وكلمة المرور)." قمنا بتعيين ملف تعريف الارتباط بشكل صريح والاحتفاظ به قبل كل حالة اختبار حتى نتمكن من الاستمرار في تسجيل الدخول والذهاب مباشرة إلى الصفحات التي نختبرها. نقوم أيضًا بإجراء بعض الإعداد أو هدم واجهة برمجة التطبيقات وتجاوز صفحة تسجيل الدخول في كل مرة كما هو موضح أدناه.

خواطر نهائية

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

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

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

لمزيد من المعلومات حول اختبارات Cypress E2E على وجه التحديد ، تحقق من الموارد التالية:

• نظرة عامة على 1000 قدم لكتابة اختبارات السرو
• TypeScript كل الأشياء في اختبارات السرو الخاصة بك
• التعامل مع تدفقات البريد الإلكتروني في اختبارات السرو
• أفكار لتكوين وتنظيم وتوحيد اختبارات السرو الخاصة بك
• دمج اختبارات السرو مع Docker و Buildkite و CICD