كيف تبني خط أتمتة اختبارات Salesforce في الـ CI

خط أتمتة اختبارات Salesforce بيشغّل اختبارات Apex ومكوّنات Lightning Web آليًا مع كل commit، قبل ما الكود يوصل الإنتاج. الإعداد الشغّال بيربط مستودع git بمشغّل CI، بيشغّل scratch org أو sandbox، بينشر الميتاداتا، بيشغّل الاختبارات، وبيفشّل الـ build لو التغطية نزلت تحت الـ 75 بالمية اللي Salesforce بتطلبها. الدليل ده بيمشي على الخط كله، من أول مستوى اختبار لحد الفخاخ اللي بتبطّئ الفرق.

ما هي أتمتة اختبارات Salesforce في الـ CI؟

التكامل المستمر (CI) هو ممارسة التحقق من كل تغيير أول ما ينزل، بدل ما يكون عند بوابة الإصدار. بالنسبة لـ Salesforce، ده معناه خط بيشغّل اختباراتك الآلية مع كل push أو pull request، وبيمنع الدمج لو حاجة فشلت. الهدف هو اختبار shift-left: تمسك trigger مكسور أو تأكيد فاشل في دقايق على branch، مش في نشر ليلة الإصدار على الإنتاج.

Salesforce عندها قاعدة صارمة بتخلّي ده لا غنى عنه: قبل ما تنشر Apex للإنتاج، لازم اختباراتك تنجح وتبقى عندك تغطية 75 بالمية على الأقل. الـ CI هو إزاي تخلّي ده أخضر باستمرار بدل الهرجلة وقت النشر.

ماذا يجب أن تختبر مع كل commit؟

مجموعة اختبارات Salesforce المفيدة بتبقى طبقات. اهدف تغطي، الأسرع الأول:

• اختبارات Apex الوحدوية: العمود الفقري. غطِّ الـ triggers والـ classes ومنطق العمل بتأكيدات ذات معنى، مش مجرد حشو تغطية.
• اختبارات LWC Jest: منطق مكوّنات Lightning Web، بتتشغّل بـ @salesforce/sfdx-lwc-jest. دي سريعة وبتشتغل من غير org.
• اختبارات التكامل والـ smoke: طبقة رفيعة بتتأكد من المسارات الحرجة من طرف لطرف والتكاملات الخارجية بعد النشر.

شغّل Apex وJest مع كل commit لأنهم سريعين، واحجز فحوصات الواجهة الأبطأ لمرحلة ليلية. دليلنا عن إيه اللي يشتغل في كل pull request وإيه اللي بالليل بيفصّل التقسيمة دي.

كيف تُعِدّ خط CI لاختبارات Salesforce؟

الأجزاء المتحركة واحدة سواء استخدمت GitHub Actions أو GitLab CI أو Jenkins. الخط الأدنى بيعمل ده مع كل pull request:

1. وثّق الدخول لـ Salesforce CLI على Dev Hub، عادةً بتدفق JWT وشهادة مخزّنة.
2. اعمل بيئة: شغّل scratch org (أو استهدف sandbox مخصص للـ CI).
3. انشر المصدر بـ sf project deploy start.
4. شغّل الاختبارات بـ sf apex run test --test-level RunLocalTests --code-coverage --result-format human، وشغّل npm run test:unit لاختبارات LWC Jest.
5. اربط الـ build بالنتيجة، وبعدين احذف الـ scratch org علشان ما يفضلش حاجة معلّقة.

Salesforce ناشرة شرح رسمي لـ Salesforce DX مع GitHub Actions بيتطابق بسلاسة مع الخطوات دي.

أي مستوى اختبار Apex يستخدمه الـ CI؟

مستوى الاختبار بيتحكم في كمية اللي بتتشغّل والوقت اللي الـ build بياخده:

• RunLocalTests بيشغّل كل اختبار في الـ org ما عدا اختبارات الـ managed packages المثبّتة، وهو الافتراضي الآمن لخط التحقق.
• RunSpecifiedTests بيشغّل الـ classes المسمّاة بس، مفيد لتغذية راجعة سريعة على الـ branch لكن خطر كبوابة إنتاج لأنه ممكن يفوّت تغطية.
• مستوى أحدث RunRelevantTests نزل بيتا في إصدار Spring '26 علشان يقصّر النشر بتشغيل الاختبارات المتأثرة بالتغيير بس؛ عامله كبيتا لحد ما تتحقق منه مع مجموعتك.

للـ build اللي بيمنع الدمج، فضّل RunLocalTests علشان التغطية تكون حقيقية. استخدم الاختبارات المحددة أو ذات الصلة بس لتغذية راجعة سريعة غير مانعة في وقت أبكر على الـ branch.

أين تخطئ الفرق في CI الخاص بـ Salesforce؟

تلات أخطاء بتفسّر معظم الخطوط المتعطّلة:

الجري ورا رقم الـ 75 بالمية بدل التأكيدات الحقيقية. التغطية من غير تأكيدات بتعدّي البوابة وبتشحن الأخطاء برضه.

التانيين هم بيانات اختبار غير موثوقة، ومجموعة بتكبر لحد ما تبقى بطيئة على التشغيل مع كل commit. حُل الأولى بإنشاء بيانات الاختبار جوّه كل اختبار بنمط factory ومع @testSetup، ومتعتمدش أبدًا على بيانات الـ org. وحُل التانية بفصل اختبارات الوحدة السريعة عن اختبارات النهاية للنهاية البطيئة، علشان التغذية الراجعة تفضل تحت كام دقيقة في المكان الأهم. أدوات فئة Salesforce DevOps، منها Copado وGearset وSalto وAutoRABIT وFlosum وBlue Canvas، ممكن تغلّف الخطوات دي في خط مُدار لو مش عايز تبني الـ YAML بإيدك.

لمزيد من أدلة Salesforce DevOps، شوف مكتبة المصادر بتاعتنا.

FAQ

ما نسبة تغطية الكود التي تطلبها Salesforce للنشر؟

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

هل أحتاج scratch orgs لـ CI الخاص بـ Salesforce؟

لا، لكنها بتساعد. الـ scratch orgs بتدّي كل build بيئة نظيفة وقابلة للتخلص منها. الـ sandbox المخصص للـ CI بيشتغل كمان لو تتبع المصدر وإعادة الضبط اتداروا بعناية.

كيف أختبر مكوّنات Lightning Web في الـ CI؟

استخدم مشغّل @salesforce/sfdx-lwc-jest المبني على Jest. بيشغّل اختبارات المكوّنات محليًا من غير org، فسريع كفاية للتشغيل مع كل commit.

أي أداة CI هي الأفضل لـ Salesforce؟

GitHub Actions وGitLab CI وJenkins كلهم بيشتغلوا كويس مع Salesforce CLI. المشغّل أقل أهمية من خط نظيف: وثّق الدخول، انشر، شغّل الاختبارات، اربط البوابة، نظّف.