Jenkins / الأدلة والمشاركة والسلطة / الدرس 7
تقارير الاختبار وسياسة نتيجة البناء
افصل تنفيذ الاختبار ونشر JUnit وعدم الاستقرار وبوابة الإصدار.
في هذه الصفحة
أهداف الدرس
- شرح فرق نشر التقرير وتشغيل التأكيدات.
- تحديد سلوك الفشل وعدم الاستقرار والغياب والإلغاء.
لا ينفذ الناشر التأكيدات
ينتج أمر الاختبار ملاحظات وتقريراً مقروءاً آلياً غالباً. ينشر Jenkins صيغة JUnit المدعومة بإضافتها، لكن النشر ليس الاختبار. تفحص وحدة Parcel تطبيع الملصق ويسجل الناشر الحالات والفشل للتنقل والتاريخ. إذا لم يعمل الأمر فقد يضلل تقرير قديم في المجلد. اربط التقرير بالتشغيل والمصدر وتحقق من منتجه، وافصل الغياب عن صفر إخفاقات. لا يعني وجود الملف أنه جُدد، كما لا يثبت عدد الحالات وحده أنها تغطي المتطلبات التي يعتمد عليها قرار إصدار المرشح.
للنجاح وعدم الاستقرار وعدان مختلفان
قد يجعل نشر JUnit البناء unstable عند وجود إخفاقات وفق الافتراضات والخيارات الموثقة. وقد يفشل الأمر مستقلاً أو يُلغى التشغيل. قرر النتائج التي تحجب الإصدار. يمكن الاحتفاظ بتحقق مكتمل غير مستقر مع منع الترقية، لكن لا تساوِه صامتاً بدليل مطلوب ناجح. راجع شروط المراحل وخيارات Declarative وفق السياسة. الألوان عرض، ويجب أن يحدد العقد الملاحظات المقبولة صراحة. بذلك يستطيع المراجع تفسير تشغيل احتفظ بتقرير مفيد دون الادعاء أن كل الاختبارات نجحت أو أن الحزمة أصبحت مؤهلة تلقائياً.
اجعل المسار والغياب ذوي معنى
ينشر المقطع نمطاً محدداً ولا يقبل نتائج فارغة. يفترض إضافة JUnit وملفات جديدة مطابقة في مساحة مخصصة، ولا ينفذ أو يختلق نتيجة. ضيق النمط لتجنب مجموعات قديمة أو غير مرتبطة. إن احتجت النشر بعد أمر فاشل فضعه بمسار post أو معالجة نتائج مناسب مع حفظ فشل الأمر. لا تُفعل allowEmptyResults لمجرد إسكات خطأ مسار، فقد تحذف الدليل المطلوب. يحتاج التصحيح إثبات أن التقرير المقصود ظهر، لا مجرد اختفاء رسالة غياب الملفات من السجل.
junit testResults: "reports/unit-*.xml", allowEmptyResults: falseلا تعمل خطوة الإضافة إلا في Pipeline فعلي مصرح. لا تشغّل اختبارات أو تنشئ تقارير أو تثبت صيغة أي منتج. لا تُثبت إضافة هنا.
افحص تقريراً صغيراً صريحاً محلياً
يحلل البرنامج الكامل مجموعة XML افتراضية ويعد عناصر failure ويقارن العدد المعلن بعناصر testcase. هو تمرين بنية محدود لا تحقق لكل لهجات JUnit أو سلوك الإضافة. تختلف وحدات الوقت والتخطي والتداخل وتمثيل الخطأ بين المنتجين. راجع توقعات الناشر وافحص تقارير ممثلة في مختبر مصرح منفصل عند الحاجة. قد يكون XML سليماً ويصف تشغيلاً خاطئاً أو تغطية ناقصة. لذلك لا تخلط نجاح التحليل وصحة علاقة التقرير بالمرشح أو كفاية الحالات؛ كلها أسئلة مستقلة في سلسلة الأدلة.
from xml.etree import ElementTree as ET
xml = '<testsuite tests="2"><testcase name="trim"/><testcase name="uppercase"><failure message="expected uppercase"/></testcase></testsuite>'
suite = ET.fromstring(xml)
cases = suite.findall("testcase")
print(len(cases) == int(suite.attrib["tests"]))
print(sum(c.find("failure") is not None for c in cases))True
1يقرأ البرنامج النص المضمن فقط. يتضمن إخفاقاً واحداً عمداً ولا يشغّل مجموعة فعلية أو ناشر Jenkins.
استخدم دليلاً كاملاً حديثاً للقرار
يجب أن تعرف البوابة المجموعات المطلوبة ومراجعة منتجها وحالات قبولها وحداثتها. نجاح الرفع دليل النشر لا نجاح الاختبار. تجنب الإعادة حتى النجاح دون حفظ المحاولات وعيّن مسؤول عدم الاستقرار بدلاً من إخفائه بتقرير اختياري. افصل فشل التطبيق وقناة التقرير ليعالجا مستقلاً. بعد إصلاح المسار تحقق من ظهور الحالات المطلوبة وبقاء الحالة الافتراضية الفاشلة قادرة على حجب العقد. يفيد ذلك في كشف إصلاح أسكت الخطأ بتخفيف الشرط بدلاً من استعادة الدليل المفقود فعلاً.
الأخطاء الشائعة وإصلاحها
يوصف نشر XML كتشغيل الوحدة.
- لماذا يحدث؟
- اختلط مستهلك التقرير بمنتج التأكيد.
- كيف تصلحه؟
- شغّل المجموعة وانشر تقريرها الجديد منفصلاً.
- كيف تتجنب تكراره؟
- وثق الأمر والمسار وسياسة النتائج معاً.
تخفي allowEmptyResults تقريراً إلزامياً غائباً.
- لماذا يحدث؟
- تحول خطأ مسار إلى غياب مقبول.
- كيف تصلحه؟
- أصلح المنتج أو المسار واحفظ رفض الدليل الناقص.
- كيف تتجنب تكراره؟
- جرّب حالة لا تقرير بخطة تحقق مضبوطة.
تُرقّى مجموعة unstable كأنها نجحت.
- لماذا يحدث؟
- تعتمد السياسة تفسيراً غامضاً لغياب الفشل.
- كيف تصلحه؟
- اشترط نتائج مقبولة صريحة لكل مجموعة.
- كيف تتجنب تكراره؟
- راجع النجاح وعدم الاستقرار والفشل والتخطي والإلغاء.
اختبر فهمك
1. تقرير قديم بلا إخفاق والأمر الحالي لم يبدأ. هل اختُبر المرشح؟
اعرض الحل المشروح
لا. لا يخص التقرير التنفيذ الحالي. أثبت المنتج والحداثة واحصل على نتيجة المجموعة المطلوبة. لا يربط XML سليم ونشر ناجح التقرير بالمصدر المقصود تلقائياً.
2. لماذا نحفظ unstable بعد إعادة ناجحة؟
اعرض الحل المشروح
يحوي دليلاً مفيداً للفشل وعدم الاستقرار. احفظ المحاولات وحقق السبب وطبق سياسة الإعادة. تفيد نتيجة لاحقة دون محو إخفاق سابق على المدخلات نفسها.
أهم ما تعلمته
- التنفيذ والنشر والأهلية منفصلة.
- يحتاج الغياب وعدم الاستقرار سياسة صريحة.