كيف تشغّل اختبارات Apex بالتوازي من غير فشل عشوائي

علشان تشغّل اختبارات Apex بالتوازي من غير فشل عشوائي (flaky)، خلّي كل اختبار ينشئ بياناته بنفسه، وما تكتبش أبدًا في سجلات موجودة خارج الاختبار، وولّد قيم فريدة للحقول زي أسماء المستخدمين. وبعدها شخّص أي فشل عشوائي متبقي بإعادة تشغيل الكلاس ده لوحده: لو نجح لوحده وفشل بالتوازي، يبقى عندك مشكلة عزل مش bug. أما إيقاف التشغيل المتوازي على مستوى الـ org كلها فبيخبّي العَرَض وبيبطّأ كل تشغيل.

لماذا تفشل اختبارات Apex فقط عند تشغيلها بالتوازي؟

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

• التنافس على أقفال السجلات. المعاملة اللي مستنية سجل مقفول بتاخد 10 ثواني قبل ما Salesforce ترجّع UNABLE_TO_LOCK_ROW، والحد ده مش قابل للتغيير، زي ما بتشرح Xappex. السجلات الأب بتتقفل في صمت عند تحديث سجلات الأبناء في علاقة master-detail، وعند إعادة حساب roll-up summaries، وأثناء معالجة المشاركة (sharing).
• قيم فريدة على مستوى Salesforce كلها. أسماء المستخدمين فريدة في Salesforce بالكامل، فلو كلاسين أدخلوا [email protected] في نفس الوقت هيفشلوا بخطأ DUPLICATE_USERNAME، وده نمط بيوثّقه Salesforce Central.
• بيانات org مشتركة. الاختبار اللي بيستخدم @isTest(SeeAllData=true) بيقرا ويكتب في سجلات حقيقية ممكن اختبارات تانية تلمسها في نفس الوقت.

ولا واحدة من دي بتظهر لما الكلاس يشتغل لوحده، وعلشان كده الـ suite بتبان كأنها بتفشل عشوائيًا.

كيف تفرّق بين فشل التوازي العشوائي والـ bug الحقيقي؟

1. اقرأ رسالة الخطأ. UNABLE_TO_LOCK_ROW وDUPLICATE_USERNAME وأي أخطاء قيم مكررة على بيانات الاختبار بتشاور على مشكلة تزامن.
2. شغّل الكلاس لوحده. الخيار --synchronous في Salesforce CLI بيشغّل methods الاختبار في كلاس Apex واحد بشكل متزامن، بحسب توثيق plugin-apex.
3. قارن. نجح لوحده وفشل بالتوازي: مشكلة عزل. فشل في الحالتين: عيب حقيقي. صلّحه، ما تعيدش تشغيله وخلاص.
4. سجّل الحالة. اكتب اسم الكلاس والخطأ والتاريخ. الكلاس اللي بيفشل عشوائيًا مرتين في الشهر يطلع أول قائمة الإصلاح.

كيف تجعل اختبارات Apex آمنة للتشغيل المتوازي؟

1. أنشئ كل بيانات الاختبار داخل الاختبار. استخدم @TestSetup أو data factory واستغنَ عن SeeAllData=true. الاختبارات اللي بتبني بياناتها بنفسها ما بتتنافسش على سجلات الـ org.
2. خلّي الكتابة في سجلات الاختبار نفسه بس. تجنّب تحديث سجلات الإعداد المشتركة أو المستخدم المشغّل أو أي حاجة ممكن إعادة حساب المشاركة تقفلها.
3. خلّي الحقول الفريدة فريدة لكل كلاس. ضيف قبل أسماء المستخدمين والقيم الفريدة التانية اسم كلاس الاختبار ورقم عشوائي.
4. افصل اختبارات الوحدة عن اختبارات التكامل. المنطق اللي تقدر تختبره من غير DML عمره ما بياخد قفل. وخلّي الاختبارات التقيلة المرتبطة بالبيانات في مجموعة أصغر تقدر تراقبها كويس.
5. علّم الكلاسات المضمونة. أضاف إصدار Winter '18 التعليق @isTest(isParallel=true) لتمييز الكلاسات اللي تقدر تشتغل بالتوازي من غير حدود التزامن الافتراضية، زي ما بيوضح FishOfPrey. ضيفه بس للكلاسات اللي بتنجح بشكل متكرر في التشغيل المتوازي.

هل تفعّل Disable Parallel Apex Testing وخلاص؟

كحل مؤقت بس. الإعداد موجود في Setup ثم Apex Test Execution ثم Options، وبيشغّل الاختبارات غير المتزامنة واحد ورا التاني. ده بيشيل فشل التزامن، لكن في الـ orgs اللي فيها كلاسات اختبار كتير التشغيل الكامل ممكن ياخد وقت أطول بكتير. وفيه أدوات بتعتمد على نفس الإعداد: توثيق Gearset بيذكر إن test monitors عندها بتستخدم Tooling API وبالتالي بتشغّل الاختبارات بالتوازي إلا لو فعّلت الإعداد ده.

اعتبر الخانة دي علامة على دَين تقني. فعّلها علشان تعدّي release، وبعدين صلّح الكلاسات المسببة للمشكلة ورجّعها مقفولة.

كيف تشغّل اختبارات Apex المتوازية بشكل موثوق في CI؟

• شغّل بشكل غير متزامن افتراضيًا. الأمر sf apex run test --test-level RunLocalTests بيديك نفس التشغيل المتوازي اللي هتشوفه عمليات النشر على الإنتاج.
• احفظ النتائج بصيغة تقراها الأدوات. ضيف --result-format junit --output-dir علشان الـ pipeline تتابع الفشل لكل كلاس على مدار الوقت، و--code-coverage علشان التغطية تفضل واضحة.
• صنّف الأول، وبعدين أعد المحاولة مرة واحدة. أعد تشغيل الأخطاء اللي ليها بصمة تزامن بس، وبشكل متزامن. لو نجحت، سجّلها كـ flake؛ ولو فشلت، خلّي الـ build يفشل.
• راقب معدل الفشل العشوائي. لو العدد بيزيد، فدي مشكلة في تصميم الاختبارات مش في المنصة.

إعادة المحاولة العمياء مغرية، لكنها بتحوّل العيوب الحقيقية لـ builds خضرا. ونفس الانضباط ده مطلوب لما تغيّر أدواتك، زي ما شرحنا في كيف تغيّر أداة Salesforce DevOps من غير ما تكسر الـ pipeline ودليلنا عن الانتقال من Gearset إلى Serpent من غير توقف.

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

من هي Tekunda؟

Tekunda هي شركة الاستشارات والمنتجات على Salesforce اللي بتبني Serpent، منصة Salesforce DevOps فيها إدارة إصدارات عبر GitHub وpipelines نشر مؤتمتة. لو الاختبارات العشوائية معطّلة إصداراتك، قارن الخطط في صفحة الأسعار.

FAQ

هل تشغّل Salesforce اختبارات Apex بالتوازي افتراضيًا؟

نعم، التشغيل غير المتزامن بينفّذ الكلاسات في نفس الوقت، إلا لو كان Disable Parallel Apex Testing مفعّل في Setup.

ما سبب UNABLE_TO_LOCK_ROW في اختبارات Apex؟

معاملتين عايزين نفس السجل، وغالبًا بيكون سجل أب مقفول بسبب تحديث master-detail أو roll-up summary أو إعادة حساب المشاركة. المعاملة المستنية بتفشل بعد 10 ثواني.

هل أعيد تشغيل اختبارات Apex العشوائية تلقائيًا؟

مرة واحدة، بشكل متزامن، ولأخطاء التزامن بس. سجّل كل حالة وصلّح الكلاس بدل ما تعتمد على إعادة المحاولة.

هل يكفي isParallel=true لحل الاختبارات العشوائية؟

لا. هو بس بيعلّم الكلاس إنه آمن للتشغيل المتوازي. الاختبار لسه لازم ينشئ بياناته بنفسه ويستخدم قيم فريدة.