فئة اختبار Apex
تتطلب عمليات النشر إلى الإنتاج تشغيل فئات اختبار Apex ونجاحها؛ تخطي التغطية أو التلاعب بها من أكثر المفاجآت شيوعًا في يوم الإصدار.
التعريف
فئة اختبار Apex هي فئة موسومة بـ @isTest تحتوي على طرق اختبار تُشغّل كود Apex آخر؛ تتطلب Salesforce تغطية اختبار لا تقل عن 75% على مستوى المؤسسة، دون ترك أي trigger فردي بلا تغطية، قبل أن تتمكن البيانات الوصفية التي تحتوي على Apex من النشر إلى الإنتاج، رغم أن بيئات sandbox وscratch orgs لا تفرض ذلك بنفس الطريقة. تعمل طرق الاختبار افتراضيًا على نسخة جديدة ومعزولة من بيانات المؤسسة، وليس على سجلات حقيقية، ما لم يتم وسم الطريقة صراحةً بـ @isTest(SeeAllData=true)، وهو ما يفسر سبب نجاح الاختبارات التي تعتمد ضمنيًا على بيانات المؤسسة محليًا بينما تفشل في خط أنابيب CI/CD نظيف. نسبة التغطية وحدها لا تضمن أن الاختبار ذو معنى: الاختبارات الخالية من التوكيدات (assertions) التي لا وجود لها إلا لتحقيق عتبة 75% تجتاز بوابة النشر بينما لا تختبر شيئًا، وهي طريقة شائعة تجعل خطوط الأنابيب "الخضراء" تشحن منطقًا معطلاً رغم ذلك. تغطي اختبارات Apex الكود فقط أيضًا، وليس مسار النقر أبدًا، وهو ما يفسر وجود موصلات لأدوات اختبار الواجهة مثل Provar ضمن خارطة طريق Serpent. يغطي دليل خط أنابيب CI/CD لدينا تشغيل اختبارات Apex كجزء من البناء (build).
إزاي بيشتغل في Serpent
يُشغّل Serpent اختبارات Apex كجزء من الفحص المسبق (preflight) قبل إطلاق النشر، لا بعده، بحيث يمنع فشل التغطية أو التوكيد الإصدار بدلاً من أن يظهر في الإنتاج. تبقى نتائج الاختبارات والسجلات مرفقة بالمهمة التي أطلقتها، بحيث يمكن تتبع الإخفاقات إلى التغيير الذي تسبب بها. راجع إدارة الإصدارات في Serpent لمعرفة كيفية عمل فحوصات preflight.

ابدأ مجانًا. بدون بطاقة ائتمان، وبدون تثبيت، وبدون التزام.
يتم الإعداد في أقل من 15 دقيقة. لا حاجة لتوظيف متخصص DevOps.
