يتيح MSTest 4.4 تشغيل مشاريع الاختبارات باستخدام نموذج النشر نفسه الذي قد يعتمد عليه التطبيق في الإنتاج، عبر توليد مصدر الاختبارات وتمكين Native AOT والتقليص. الفكرة لا تستهدف استبدال تشغيل الاختبارات المُدار المعتاد، بل إضافة مسار أصلي يكشف مشكلات مرتبطة بالتجميع المسبق وحذف الشيفرة غير المستخدمة قبل شحن التطبيق.
وبحسب Amaury Levé، Principal Software Engineer، فإن استخدام MSTest.Sdk/4.4.0 مع استهداف net10.0 وتعيين PublishAot=true يفعّل توليد مصدر MSTest ومسار الملف التنفيذي الأصلي. ويستخدم MSTest.Sdk منصة Microsoft Testing Platform، أو MTP، افتراضياً. أما المشاريع التي ما زالت تستخدم VSTest فعليها مراجعة إرشادات الانتقال إلى MTP، لأن معاملات سطر الأوامر وتكامل CI وبعض إدخالات .runsettings المدعومة تختلف.
ما الذي يتغير عملياً؟
بعد إعداد المشروع، ينبغي نشر الاختبارات لنظام التشغيل والمعمارية نفسيهما اللذين يستهدفهما التطبيق. يورد المصدر مثالاً باستخدام المعرّف linux-x64، مع إمكانية استبداله بقيم مثل win-x64 أو osx-arm64. وبعد النشر يُشغّل الملف التنفيذي الناتج مباشرة، أو باستخدام الامتداد .exe على Windows.
هذا المسار يقلل الاعتماد على الفحص الانعكاسي الشامل للتجميع، مثل استدعاء Assembly.GetTypes()، كما يستخدم سمات ومفوضات مولدة لإنشاء الاختبارات المدعومة واستدعائها. لكن توليد المصدر لا يعني انعدام Reflection؛ إذ يحتفظ وضع ReflectionFree الافتراضي ببعض المسارات الانعكاسية الاحتياطية. وعند التحقيق في مشكلات التوافق، يمكن استخدام MSTestSourceGenMode=Rooting للحفاظ على أعضاء الاختبارات المكتشفة مع استمرار التنفيذ الانعكاسي.
مسار CI محدود قبل التوسع
التوصية العملية هي الإبقاء على تشغيل الاختبارات المُدارة السريع للتغذية الراجعة اليومية، ثم اختيار مشروع اختبارات واحد ذي صلة مباشرة بمسار النشر وإضافة تجربة Native AOT في CI. يجب مقارنة المسارين في ثلاثة جوانب واضحة:
- اكتشاف العدد نفسه تماماً من الاختبارات.
- الحصول على النتائج نفسها للاختبارات.
- تسجيل زمن النشر والتشغيل الأصلي منفصلاً عن زمن تنفيذ الاختبارات.
يفضل بدء التجربة في مهمة مجدولة أو في مرحلة التحقق من الإصدار، ثم نقلها إلى كل طلب دمج فقط إذا كانت الإشارة التي توفرها تستحق كلفة النشر والتشغيل الإضافية. كما ينبغي اختيار مشروع يختبر مسارات حساسة للنشر، مثل التسلسل، وحقن الاعتماديات، وربط الإعدادات، والإضافات المعتمدة على Reflection، أو مكتبة تحتاج الفرق إلى إثبات توافقها مع Native AOT. أما مشروع يضم اختبارات حسابية بسيطة فقط، فلن يقدم دليلاً كبيراً على جاهزية التطبيق الفعلية.
قيود يجب تحويلها إلى بوابات قبول
قد ينجح جزء من الاختبارات وتخرج العملية بنجاح رغم عدم تسجيل بعض الأصناف. يحدث ذلك، مثلاً، عندما يرث صنف الاختبار السمة [TestClass] فقط بدلاً من التصريح بها مباشرة، أو عندما يكون الصنف غير متاح، أو محلياً للملف، أو ثابتاً، أو مفتوحاً عاماً، أو مجرداً. ويشير المصدر إلى أن التشخيص MSTEST0069 يساعد في كشف إحدى هذه الحالات. لذلك فإن تطابق عدد الاختبارات يجب أن يكون شرط إصدار، لا ملاحظة يمكن تجاهلها.
وتشمل القيود الأخرى أساليب الاختبار العامة، أو التي تستخدم معاملات ref أو out أو in، إضافة إلى عدم دعم بعض أنماط الأجزاء الثابتة عبر [AssemblyFixtureProvider]. كما أن بعض تكاملات MSTest SDK وامتدادات MTP وتقارير CI غير متاحة في مسار Native AOT، بينما يظل دعما TRX وCode Coverage متاحين وفق المادة. ولهذا ينبغي التعامل مع تحذيرات المحلل وتشخيصات البناء كبوابات للانتقال، لا كتحذيرات تُسكت.
لماذا يهم هذا الأسلوب؟
الاختبار المُدار ومسار Native AOT يجيبان عن سؤالين مختلفين: الأول يسرّع دورة التطوير، والثاني يتحقق من أن الاختبارات نفسها تستطيع العمل ضمن نموذج النشر الذي سيستخدمه التطبيق. هذا لا يعادل اختباراً شاملاً لقطعة الإنتاج النهائية؛ فالإعدادات ونظام التشغيل والمعمارية والخدمات الخارجية والتغليف قد تختلف. لكنه يزيل متغيراً مهماً، هو اختلاف نموذج التقليص والترجمة المسبقة بين الاختبار والتطبيق.
أما تحسن الأداء فليس مضموناً ولا ينبغي أن يكون المبرر الأساسي. قد ينخفض زمن الاكتشاف والبدء بفضل توليد المصدر، لكن زمن التنفيذ، وبدء العملية، والنشر، وما تبقى من Reflection قد يهيمن على المدة الكلية. القراءة التحريرية هنا أن قيمة التجربة الأساسية هي رفع مطابقة الاختبار للنشر، حتى إن كان المكسب في السرعة محدوداً. ويظل النهج قابلاً للتراجع: إذا تجاوزت كلفة المسار الثقة التي يضيفها، يمكن خفض تكراره أو تغيير المشروع المختار أو إيقاف التجربة من دون تعطيل مجموعة الاختبارات المُدارة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.