أتمتة اختبارات Salesforce في الـ CI: إيه اللي يشتغل في كل pull request وإيه اللي بالليل

الإجابة باختصار: في كل pull request شغّل الفحوصات السريعة والحتمية بس: تحليل ثابت على الـ diff، واختبارات LWC Jest، ونشر دلتا للتحقق فقط بيشغّل اختبارات Apex اللي بتغطي الكود المتغير. وأي حاجة بطيئة أو غير مستقرة، زي تشغيل كل اختبارات الأورج ورحلات الواجهة والتكاملات الخارجية، حوّلها لمهمة ليلية. استهدف نتيجة في أقل من عشر دقايق، لأن بعد كده محدش بيقراها.

إيه اللي المفروض يشتغل في كل pull request؟

• تحليل ثابت على الـ diff. ثواني ومن غير أورج، وبيمسك المشاكل الميكانيكية قبل ما إنسان يقرا الكود.
• اختبارات Jest للـ LWC. بتشتغل بره المنصة في Node، فمش محتاجة أورج خالص.
• نشر دلتا للتحقق فقط على أورج شبه الهدف، بمستوى اختبار بيشغّل الكلاسات اللي بتغطي المتغير بس.
• فحوصات سلامة الميتاداتا. مفيش حذف غير مقصود، ومفيش بنود بروفايل أو permission set بتختفي في صمت.

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

إيه اللي مكانه المهمة الليلية؟

• تشغيل كامل لاختبارات Apex المحلية على ساندبوكس التكامل. ده اللي بيمسك الكلاس اللي ما كنتش عارف إن تغييرك بيمسّه.
• رحلات الواجهة على عمليات الشغل الأساسية.
• اختبارات التكامل اللي بتنادي أنظمة خارجية، اللي مش متحكم في زمن استجابتها ولا في توفرها.
• فحص الانحراف بين أورج التكامل والفرع، عشان اللي بيعدّل مباشرة في الـ Setup يبان الصبح.
• اتجاه التغطية على مستوى الأورج، كتقرير مش كبوابة.

أعطال الليل بتتفرز على القهوة. وده بالظبط المقصود: هي مش واقفة بين المطور وبين الدمج بتاعه.

إيه اللي مايشتغلش غير قبل الإصدار؟

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

مستويات الاختبار في Salesforce بتتراكب إزاي على ده؟

أربع مستويات، والاختيار في كل مرحلة هو معظم التصميم (دليل Metadata API).

• NoTestRun: مقبول جوه scratch org، ومينفعش أبدًا على طريق الإنتاج.
• RunSpecifiedTests: بوابة الـ PR بتاعتك. وفيه نقطة مهمة تعرفها: في المستوى ده كل كلاس وكل trigger في الحزمة لازم يوصل 75% تغطية بمفرده، محسوبة لكل مكوّن مش على مستوى الأورج (وثائق Salesforce).
• RunLocalTests: كل حاجة ما عدا اختبارات الحزم المُدارة. وده اللي بيشتغل افتراضيًا في نشر إنتاجي فيه Apex.
• RunAllTestsInOrg: بيضيف اختبارات الحزم المُدارة. نادرًا ما يكون ده المطلوب، وبطيء.

وقواعد المنصة تحت ده مش بتتغير: لازم 75% على الأقل من الـ Apex بتاعك يكون مغطى عشان تنشر للإنتاج، وكل trigger محتاج سطر مغطى على الأقل، وكل اختبار بيتنفذ لازم ينجح، مهما كانت نسبة التغطية (Salesforce Help).

إزاي تخلي دورة الـ pull request أقل من عشر دقايق؟

1. انشر الدلتا مش الأورج. اعمل تحقق على اللي الفرع غيّره بس.
2. استنتج قائمة الاختبارات. ولّد كلاسات الاختبار من المكونات المتغيرة بدل قائمة بتتصان بالإيد.
3. شغّل بالتوازي. Jest والتحليل الثابت المفروض يشتغلوا جنب تحقق الأورج مش في الطابور وراه.
4. خلّي عندك أورج هدف جاهزة. إنشاء أورج وتعبئتها لكل pull request غالبًا أكبر كتلة وقت. استخدم مجموعة جاهزة أو ساندبوكس تحقق طويلة العمر.
5. خزّن الاعتماديات مؤقتًا بين التشغيلات، بما فيها الـ CLI وحزم Node.
6. اعمل stub للنداءات الخارجية أو أجّلها. أي حاجة مش متحكم في زمن استجابتها مكانها المهمة الليلية.
7. قِس المدة وحطها في مكان ظاهر. زمن الـ pipeline بيزحف في هدوء، وفي اتجاه واحد بس.

اختبارات الواجهة مكانها فين؟

مش على الـ pull request. اختبارات الواجهة هي أبطأ وأهش حاجة في أي pipeline لـ Salesforce: الـ shadow DOM في مكونات Lightning، ومعرّفات العناصر المولّدة، وشاشات تسجيل الدخول، كلها بتكسر المحددات لأسباب مالهاش علاقة بالتغيير اللي بتراجعه.

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

إزاي تظبط بوابات التغطية؟

• احكم على الـ PR بتغطية الكود المتغير، مش بالرقم على مستوى الأورج. الرقم ده بيتحرك ببطء وبيخبّي كلاسات جديدة تمامًا من غير اختبارات ورا سنين من الكلاسات القديمة.
• سيب الحد الأدنى على مستوى الأورج كبوابة إصدار، وده مكانه الصح.
• متخليش النسبة هي الهدف. Salesforce نفسها بتنصح إنك تغطي كل حالة استخدام، الإيجابية والسلبية، والجماعية والفردية، والرقم يجي لوحده.

الدليل ده جزء من أدلة Salesforce DevOps عندنا.

FAQ

فحص الـ pull request في Salesforce يبقى سريع قد إيه؟

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

هل نشغّل كل اختبارات Apex في كل pull request؟

لأ. شغّل الاختبارات اللي بتغطي الكلاسات المتغيرة باستخدام RunSpecifiedTests، وسيب التشغيل المحلي الكامل للمهمة الليلية وتحقق الإصدار.

Salesforce بتطلب تغطية قد إيه فعلًا؟

75% من الـ Apex على مستوى الأورج للنشر في الإنتاج، وسطر مغطى على الأقل في كل trigger، وكل اختبار بيتنفذ لازم ينجح. ومع RunSpecifiedTests، كل كلاس وtrigger في الحزمة محتاج 75% بمفرده.

هل اختبارات LWC Jest محتاجة أورج؟

لأ. بتشتغل بره المنصة في Node، وعشان كده بالظبط مكانها بوابة الـ pull request مش المهمة الليلية.

اختبارات الواجهة تشتغل فين؟

مجموعة سريعة صغيرة بعد الدمج، والحزمة الكاملة بالليل. حطها على الـ pull request أسرع طريقة تعلّم الفريق يتجاهل البناء الأحمر.