أفضل الممارسات في أتمتة الاختبار — قبل ما تتعلّم أي أداة

معظم اللي بيبدأ بأتمتة الاختبار بيفتح دورة Selenium أو Playwright من أول يوم، وبيتعلم الأداة منيح. وبعد ستة شهور بيلاقي حاله عنده مئة اختبار Flaky، وكل تغيير بالواجهة بيكسّر نصهم.

المشكلة مش بالأداة. الأدوات بتتبدّل كل كم سنة، والمبادئ ما بتتبدّل. واللي بيتقنها بينقل من Selenium لـ Playwright بأسبوع، واللي ما بيتقنها بيعيد نفس الأخطاء بأداة أحدث.

١. اختبار واحد، وظيفة وحدة

كل اختبار لازم يفحص شيء محدد. إذا حسّيت إنه اختبارك بيفحص أكثر من وظيفة بنفس الوقت، هذه إشارة إنه لازم تقسمه.

ليش؟ لأنه لما يفشل، بدك تعرف شو انكسر من اسم الاختبار وحده. اختبار بيفحص التسجيل والدخول والشراء مع بعض، لما يفشل بيقولك «في شيء غلط بمكان ما» — وهذه مش معلومة.

٢. كل اختبار مستقل بحاله

ما في اختبار بيعتمد على اللي قبله. لا على بياناته، ولا على حالة تركها وراه، ولا على ترتيب التشغيل.

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

٣. كل خطوة UI هي فرصة للـ Flakiness

هذه أهم نقطة بالمقال كله. كل نقرة وكل تعبئة حقل هي احتمال فشل جديد. اختبار فيه ٢٢ خطوة واجهة ما رح يكون مستقر، مهما كتبته منيح.

الحل إنك تستعمل الـ API للخطوات التحضيرية، وتخلي الواجهة للجزء اللي فعلاً بدك تفحصه:

مثال عملي: بدل ما تسجّل مستخدم جديد بالواجهة، وتضيف منتجات للسلة بالواجهة، وتنفّذ الطلب بالواجهة، وبعدين تفتح الطلب لتحمّل الفاتورة — سجّل المستخدم بالـ API، واعمل الطلب بالـ API، وبعدين افتح الواجهة وحمّل الفاتورة. من ٢٢ خطوة لثلاثة.

وخطوات التسجيل بالواجهة؟ إلها اختبارها الخاص فيها، اللي بيفحص التسجيل بالذات.

٤. استراتيجية المُحدِّدات (Locators)

هذه أكبر مصدر لتكلفة الصيانة على الإطلاق، وأكثر واحد بينتبّه إله متأخر.

المحدّد المبني على شكل الصفحة بينكسر مع أول تعديل تصميم:

• div > div:nth-child(3) > span — بيكسر لو المصمّم زاد عنصر واحد
• مسار XPath طويل من أول الصفحة — نفس القصة
• أصناف CSS متولّدة تلقائياً زي css-1x9f8k — بتتغيّر مع كل بناء

والمحدّد المبني على القصد بيضل صامد:

• data-testid — سمة موجودة بالكود لهدف واحد: الاختبار
• الدور والاسم اللي المستخدم بيشوفهم — زر اسمه «تسجيل الدخول»
• النص الظاهر، أو الـ Label المرتبط بالحقل

القاعدة ببساطة: المحدّد لازم يوصف شو هذا العنصر، مش وين هو بالصفحة.

٥. استراتيجية الانتظار

ممنوع sleep ثابت. هو بطيء وغير مضمون بنفس الوقت: خمس ثواني كثير لما الصفحة تفتح بثانية، وقليلة لما السيرفر يزحف. النتيجة اختبارات بطيئة و Flaky مع بعض.

البديل إنك تستنى الشرط مش الوقت: إنه العنصر يظهر ويصير قابل للنقر، إنه الطلب يخلص، إنه النص يتغيّر.

والخبر الحلو: معظم الأدوات الحديثة بتعمل هذا لحالها. Playwright و Cypress فيهم انتظار تلقائي مدمج — قبل أي تفاعل بيتأكدوا إنه العنصر موجود وظاهر وجاهز، فنادراً بتحتاج تكتب انتظار يدوي أصلاً. وبـ Selenium بتستعمل WebDriverWait مع شرط صريح.

يعني بمعظم الحالات، حل هذه المشكلة هو إنك ما تحارب الأداة: خليها تستنى بطريقتها، ولا تحشر sleep بالنص.

٦. Page Object Model

بدل ملف اختبار طويل مليان كود، وزّع الكود على ملفات: كل صفحة بملف. صفحة الدخول، التسجيل، السلة. وكل ملف بيحمل المحدّدات والدوال الخاصة فيه.

النتيجة: الاختبار بيصير أسهل بالقراءة، والصيانة بتصير بمكان واحد.

٧. افحص الوظيفة، مش طريقة التنفيذ

بالـ Page Object، عرّف دالة اسمها login وحطّ جواها الخطوات: عبّي الإيميل، عبّي كلمة المرور، اضغط الزر. وبملف الاختبار استعمل login() وبس.

هيك لما تقرأ ملف الاختبار بتقرأ شو بتفحص، مش كيف بتفحصه. ولما يتغيّر شيء بالدخول — يضيفوا مربع اختيار مثلاً — بتعدّل بمكان واحد، مش بكل اختبار.

٨. التحققات بملف الاختبار

خلي الـ Assertions بملف الاختبار، مش جوّا الـ Page Object. لما تقرأ الاختبار لازم تشوف بالضبط شو عم يتأكد منه.

وفي هون فايدة جانبية مهمة: إذا لاقيت كثير اختبارات بتعمل نفس التحقق، هذا إنذار إنك بتكرّر نفسك وإنه في اختبارات زايدة. ولهذا دالة تحقق مشتركة بالـ Page Object فكرة غير مفيدة أصلاً — لأنها المفروض ما تنستعمل أكثر من مرة.

٩. بيانات الاختبار مع الاختبار

كل اختبار إله بياناته. خلّيها ظاهرة بملف الاختبار حتى تفهم السيناريو من غير ما تفتح ملفات ثانية.

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

١٠. ابنِ Mock Server

استعمل أي أداة مناسبة — WireMock أو Express أو NestJS أو غيرها — وشبّك اختباراتك فيها. هيك بتشتغل على مستوى التكامل: أسرع، أثبت، وتحكّم كامل بالردود.

والقاعدة: ٩٠٪ من التغطية على مستوى التكامل — الحالات الإيجابية والسلبية مع بعض. والـ E2E لأهم رحلات المستخدم فقط.

١١. ازرع البيانات، ونضّف وراك

لازم يكون عندك طريقة تزرع فيها البيانات اللي بتحتاجها قبل الاختبار، وتنضّفها بعده.

غير هيك، قاعدة بيانات الـ Staging رح تمتلئ بآلاف الطلبات والمستخدمين الوهميين خلال شهور، لحد ما تصير البيئة نفسها بطيئة وغير موثوقة. نضّف دايماً بعد ما تخلص.

١٢. خلي التصحيح سهل

لما يفشل اختبار، لازم تعرف ليش خلال ثواني — مش خلال نص ساعة.

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

بالنهاية

لاحظ إنه ولا مبدأ من اللي فوق مرتبط بأداة معيّنة. كلهم بيشتغلوا مع Selenium، ومع Playwright، ومع اللي رح يطلع بعدهم.

هذا هو الفرق بين واحد «بيعرف Playwright» وواحد بيعرف أتمتة الاختبار. الأول بيوقف لما تتغيّر الأداة؛ والثاني بينقل معه كل شي.

فإذا لسا بالبداية: اتعلّم الأداة، أكيد — بس اتعلّم هذه المبادئ وإنت بتتعلّمها. والأداة رح تصير تفصيل.