لا تكمن المشكلة في ظهور بناء أحمر بحد ذاته، بل في معرفة ما إذا كان سببه تراجعاً جديداً، أو اختباراً متقطعاً، أو تعطل مضيف الاختبار الذي أزال الأدلة اللازمة للتحقيق. يوضح .NET Blog كيف يمكن لـ Microsoft.Testing.Platform، أو MTP، جعل تقارير الاختبارات أكثر فائدة للمطورين والمراجعين وأدوات التكامل المستمر، بدلاً من الاكتفاء بعرض قائمة طويلة من السجلات.
تستهدف هذه الممارسات الفرق التي تستخدم GitHub Actions أو Azure DevOps، وتريد أن تصل معلومات الفشل إلى نقطة اتخاذ القرار داخل طلب الدمج. كما تتيح المنصة إنتاج أكثر من صيغة للتقرير من تشغيل واحد، وتوفير مخرجات منظمة يمكن للبرامج ولوحات المعلومات وأدوات التطوير استهلاكها بثبات.
استخدم تاريخ البناء للتمييز بين التراجع والعطل المتقطع
يعرض Azure DevOps بالفعل أدلة الاختبارات في تبويب Tests، لكن تمرير نافذة تاريخية إلى المبلّغ يضيف سياقاً إلى كل فشل. فعند استخدام الخيار --report-azdo-flaky-history 14، تستعلم المنصة عن تاريخ خط الأنابيب خلال 14 يوماً، ثم تميز الاختبار الذي فشل بصورة متقطعة عن الاختبار الذي لا يملك تاريخاً مماثلاً.
يمكن أن يظهر الاختبار المتقطع بالوسم [flaky: failed 3/20 in last 14d]، بينما يحصل الفشل الذي لا يملك هذا السجل على وسم [REGRESSION]. يساعد ذلك المراجع على بدء التحقيق من المسار المناسب: فالفشل بلا تاريخ يحتاج إلى اهتمام فوري بوصفه تراجعاً محتملاً، في حين يبدأ الفشل المتكرر من سجله المعروف.
وإذا أراد الفريق أن يغيّر ذلك سلوك التكامل المستمر، فهناك الخيار --report-azdo-demote-known-flaky الذي يحوّل الأعطال المعروفة بأنها متقطعة إلى تحذيرات، مع إبقاء التراجعات أخطاء. لكن المصدر يشدد على أن القرار ينبغي أن يكون صريحاً: هل نريد استخدام التاريخ لتوجيه المراجع فقط، أم نريد أن يغيّر مستوى حدة الفشل تلقائياً؟ وفي خط أنابيب testfx، استُخدمت التعليقات التاريخية مع إبقاء كل حالات الفشل حاجزة للبناء.
ويُستخدم التاريخ نفسه لاكتشاف الاختبارات البطيئة عبر --report-azdo-slow-test-history. يقارن الخيار كل اختبار بأدائه السابق، باستخدام مضاعف قابل للضبط وفوق حد أدنى من مرات التشغيل، حتى لا يؤدي تشغيل بارد واحد إلى إطلاق إنذار غير دقيق.
احتفظ بالأدلة عندما يتعطل مضيف الاختبار
كانت النتائج بصيغة TRX تُسلسل في نهاية التشغيل، لذلك قد يؤدي تعطل حاد إلى فقدان التقرير بأكمله. أما الآن فتُكتب النتائج إلى القرص أثناء إنتاجها، وبالاقتران مع امتداد تفريغ الأعطال يمكن إنهاء التقرير الجزئي عندما يتوقف المضيف:
dotnet test --report-trx --crashdump
ينتج عن ذلك ملف TRX صالح يتضمن كل الاختبارات التي اكتملت، إلى جانب قائمة بالاختبارات التي كانت قيد التشغيل عند التعطل. كما يكتب الامتداد ملفاً بامتداد .crash.sequence.log يسجل بداية كل اختبار ونهايته، ما يساعد على تحديد الاختبار الذي بدأ ولم ينته حتى عند تشغيل اختبارات عدة بالتوازي.
وتشمل المعالجة المرفقات أيضاً. فلم تعد تفريغات الأعطال وتعليقات التوقف وملفات امتدادات الاختبار تُهمل بصمت على .NET Framework عندما يتجاوز المسار حد Windows MAX_PATH. وإذا تعذر نسخ مرفق، يظهر ذلك في وحدة التحكم، بدلاً من بقائه مذكوراً داخل ملف TRX فقط. والنتيجة أن التشغيل غير المكتمل يظهر بوضوح على أنه غير مكتمل، ولا يبدو كتقرير أخضر يخفي أدلة ناقصة.
اختر صيغة التقرير وفق الجهة المستهلكة
يمكن للتشغيل الواحد تفعيل صيغ متعددة من دون خطوة تحويل منفصلة. وتناسب صيغة TRX أدوات .NET، بينما تصلح HTML للفحص المباشر، وتفيد JUnit XML وCTRF JSON لوحات المعلومات والأتمتة العابرة للتقنيات. ويقدم CTRF مخطط JSON مشتركاً لتجميع نتائج .NET مع نتائج لغات أخرى.
تقرأ أنظمة التكامل المستمر صيغتي TRX وJUnit في عروض النتائج، أما HTML وCTRF فتظهران كملفات يمكن تنزيلها أو استخدامها في لوحات المعلومات. وفي Azure DevOps يمكن للخيار --report-azdo-upload-artifacts files رفع ملفات دليل النتائج تلقائياً. كما ينبغي تسمية الملفات باستخدام الخيار --report-<format>-filename وعناصر نائبة مثل {asm} و{tfm}، حتى لا تتعارض النتائج في المشاريع التي تستهدف أطر تشغيل متعددة.
اجعل المخرجات مستقرة وقابلة للأتمتة
يوفر الخيار --list-tests json مستنداً ذا إصدار مخطط يصف الاختبارات المكتشفة ومواقعها المصدرية. ويعد ذلك مدخلاً مستقراً لاختيار الاختبارات وتحليل أثر التغييرات وتكامل بيئات التطوير، بدلاً من تحليل نص وحدة التحكم الذي قد يتغير بين الإصدارات.
وتتكيف مخرجات MTP مع بيئات الوكلاء والنماذج اللغوية؛ إذ تُخفي الشريط التعريفي ومحارف ANSI وحركة التقدم، وتعرض افتراضياً مخرجات stdout وstderr للاختبارات الفاشلة فقط. ويمكن التحكم بالسلوك عبر NO_COLOR وخياري --ansi و--progress.
ثبّت سياسة التقارير وتحقق من التوافق
توصي المادة بتجربة MTP 2.3 أو إصدار أحدث في مشروع اختبار واحد، ثم تفعيل --report-gh في GitHub Actions أو --report-azdo في Azure DevOps. وبعد اختيار السياسة، تُحفظ الإعدادات في ملف testconfig.json داخل المستودع، بحيث تنتج عمليات التشغيل المحلية وعمليات CI التقارير نفسها. كما يمكن استخدام Directory.Build.props لتطبيق إعدادات موحدة على جميع مشاريع الاختبار، أو استخدام ملف تعريف AllMicrosoft لتفعيل المجموعة المستقرة من الامتدادات، مع بقاء JUnit وCTRF اختياريين.
على الفرق التي لا تستخدم MSTest.Sdk أن تتحقق من تطابق إصدارات حزم المبلّغات مع إصدار MTP الذي يستهدفه إطار الاختبار. ويصل دعم MTP 2.x إلى MSTest.TestAdapter 4.0.0 وNUnit3TestAdapter 6.0.1 وTUnit 1.7.16 وYoloDev.Expecto.TestSdk 0.16.0 وإصدارات المعاينة من xunit.v3 4.0. كذلك لا يدعم الحل المزج بين مشاريع MTP وVSTest، ولذلك ينبغي ضبط الاشتراك في تشغيل MTP على مستوى المستودع.
تحتاج خيارات تاريخ Azure DevOps إلى الرمز SYSTEM_ACCESSTOKEN: $(System.AccessToken). ومن دونه يستمر التشغيل، لكنه يتجاوز التعليقات التاريخية. وفي خطوط الأنابيب الحالية يمكن استبدال مهام نشر نتائج الاختبار ونشر الملفات بخيارات MTP المقابلة، لكن نشر تغطية الشيفرة لا يُستبدل؛ لذلك يجب الإبقاء على PublishCodeCoverageResults@2. كما ينبغي عدم تفعيل النشر المباشر مع PublishTestResults@2 معاً، لأن ذلك ينشئ تشغيلَي اختبار منفصلين للبناء نفسه.