كيفية إصلاح فشل اختبارات Apex وأخطاء تغطية الكود في عمليات نشر Salesforce

تتطلب عمليات النشر إلى الإنتاج اجتياز اختبارات Apex وتغطية كود لا تقل عن 75%، ويحظر Salesforce الإصدار حتى يتحقق الشرطان.

تظهر أثناء: النشر إلى الإنتاج أو تحديث كامل لبيئة sandbox

المعنى

يتطلب Salesforce أن تشغّل عمليات النشر إلى الإنتاج اختبارات Apex وأن تصل إلى تغطية كود متوسطها 75% على الأقل عبر جميع الـ classes والـ triggers، مع ضرورة وجود بعض التغطية لكل trigger. يفشل النشر، مع سرد assertion أو exception كل اختبار فاشل، عندما يطلق اختبار exception غير معالج، أو تفشل assertion، أو ينخفض متوسط التغطية في المؤسسة عن هذا الحد.

يقتصر هذا الشرط على عمليات النشر إلى الإنتاج وبيئات sandbox الكاملة باستخدام RunLocalTests أو RunAllTestsInOrg؛ أما عمليات النشر إلى Developer sandboxes أو scratch orgs باستخدام NoTestRun فتتخطى هذا الشرط تمامًا، وهذا بالضبط سبب عدم ملاحظة فجوات التغطية حتى يوم الإصدار.

التشخيص

الأسباب الشائعة

اختبار يقوم بـ assertion على بيانات غيّرها كود غير ذي صلة

يعدّل trigger أو Flow تم نشره حديثًا حقلاً يقوم الاختبار بعمل assertion عليه، فلا تعود القيمة المتوقعة للاختبار مطابقة، رغم أن الاختبار نفسه لم يُمس.

كود جديد تم إصداره بدون اختبارات تغطيه

تمت إضافة أو توسيع class أو trigger دون وجود test method مقابلة، مما يخفض متوسط تغطية المؤسسة إلى أقل من 75%.

الاختبار يعتمد على بيانات أو إعدادات خاصة بالمؤسسة

يستعلم الاختبار عن سجلات أو أنواع سجلات أو إعدادات موجودة بدلاً من إنشاء بياناته الخاصة، فينجح في مؤسسة ويفشل في أخرى لا توجد فيها تلك البيانات.

الحل

أعِد إنتاج الفشل محليًا أولاً
شغّل مجموعة الاختبارات المحلية الكاملة مع التغطية على بيئة sandbox الخاصة بك قبل لمس الكود، حتى تعمل على تصحيح الفشل الحقيقي لا سجل نشر قديم.
```
sf apex run test --test-level RunLocalTests --code-coverage --result-format human --wait 20
```
اكتب اختبارات لأي كود جديد قبل النشر
أضف test methods تمارس الـ classes والـ triggers الجديدة حتى يتجاوز متوسط تغطية المؤسسة 75% قبل الإصدار.
اجعل الاختبارات مستقلة بذاتها
أعد كتابة الاختبارات لإنشاء بيانات اختبار خاصة بها باستخدام @TestSetup أو Test.startTest() بدلاً من الاعتماد على سجلات موجودة مصادفة في المؤسسة المستهدفة.

من واقع الاستخدام

إزاي Serpent بتمنع ده

تعرض إضافة VS Code من Serpent نتائج الاختبار والتغطية على المهمة نفسها، بحيث تصبح فجوة التغطية أو فشل assertion مرئية قبل تقديم المهمة، بدلاً من اكتشافها أثناء عملية نشر إلى الإنتاج. راجع مكتبة أخطاء نشر Salesforce.

الإصدارات

المهام

المؤسسات

v2.8.3 · الإنتاج

المكوّنات

○

AccountTrigger

○

OpportunityFlow

○

DashboardLWC

○

PermissionSet_A

○

EmailTemplate

0 من 5 جاهزة

مراجعة Serpent بالذكاء الاصطناعي

جارٍ التحليل…

○

لا تغييرات جذرية

○

تغطية الاختبار: 94%

○

تم رسم التبعيات

○

تم التحقق من الفروقات

في انتظار مراجعة الذكاء الاصطناعي…

✓ تم النشر إلى الإنتاج · للتو

الوقاية

اربط عمليات الدمج بالتغطية، لا فقط بالنجاح أو الفشل

اجعل CI يفشل عند أي pull request يُخفّض التغطية على مستوى المؤسسة إلى أقل من 75%، وليس فقط عند فشل اختبار صريح، حتى لا تصل الفجوة أبدًا إلى الإصدار.

لا تقم أبدًا بعمل assertion على أعداد السجلات بدون تقييد WHERE

قيّد كل استعلام assertion بالسجلات التي أنشأها الاختبار نفسه، حتى لا تكسر أتمتة غير ذات صلة تُضاف لاحقًا الـ assertion بصمت.

شغّل تحقق RunLocalTests قبل كل إصدار إنتاج

ابدأ عملية نشر check-only باستخدام RunLocalTests قبل الإصدار الفعلي حتى تظهر الأخطاء مع وقت كافٍ لإصلاحها، لا أثناء نافذة النشر.

أسئلة شائعة

APEX TEST FAILURES، بالإجابات

هل تضمن تغطية 75% نجاح النشر؟

لا. التغطية هي حد أدنى، وليست معيار جودة. لا يزال يتعين على كل اختبار أن ينجح فعليًا؛ يمكن لمجموعة اختبارات أن تصل إلى تغطية 75% وتفشل عملية النشر مع ذلك إذا أطلق اختبار واحد فقط exception غير معالج أو فشلت assertion.

هل تحتاج كل class على حدة إلى تغطية 75%؟

لا، حد 75% هو متوسط على مستوى المؤسسة بأكملها. يمكن أن تقل classes فردية عنه طالما أن المتوسط العام يتجاوز الحد، رغم أن كل trigger لا يزال بحاجة إلى بعض التغطية على الأقل.

لماذا بدأ اختبار لم يتغير أبدًا يفشل فجأة؟

تغيّر شيء آخر في المعاملة نفسها: أصبح trigger أو Flow أو validation rule جديد يلمس بيانات يقوم الاختبار بعمل assertion عليها. تحقق مما تم نشره أيضًا إلى جانب الاختبار الفاشل.

ابدأ مجانًا. بدون بطاقة ائتمان، وبدون تثبيت، وبدون التزام.

يتم الإعداد في أقل من 15 دقيقة. دون الحاجة لتوظيف متخصص DevOps.

ابدأ مجانًا احجز عرضًا تجريبيًا