كتابة حالات اختبار helm

يتحقق كل من lint وtemplate من الملفات، لكن helm test يفحص إصدارًا يعمل بالفعل في عنقودكم. فهو يثبت أن التطبيق يعمل فعلًا. ✅

اختبار Helm هو Pod معرّف في دليل templates الخاص بالمخطط. يشغّله Helm عند الطلب، ويحدّد نجاحه من خلال رمز الخروج.

تضعون علامة على Pod بوصفه اختبارًا بإضافة التعليمة helm.sh/hook: test. عندها يتجاهله Helm أثناء التثبيت ولا يشغّله إلا عند طلب ذلك.

يشغّل أحد الاختبارات الشائعة صورة صغيرة مثل busybox تستخدم wget للتأكد من أن الخدمة تستجيب على منفذها.

إذا خرج Pod الاختبار بالرمز 0، ينجح الاختبار. ويؤدي أي رمز خروج غير صفري إلى اعتباره فاشلًا، تمامًا كما يحدث مع أمر shell.

بعد التثبيت، شغّلوا helm test مع اسم الإصدار. ينشئ Helm Pods الاختبار، وينتظرها، ويعرض نتيجة كل منها.

أضيفوا --logs لبث ناتج كل Pod اختبار، حتى يخبركم الفشل بما حدث بدلًا من إخباركم بأنه فشل فحسب.

لا تُشغَّل الاختبارات تلقائيًا أثناء التثبيت. بل تشغّلونها بأنفسكم، مما يحافظ على سرعة التثبيت ويجعل الاختبارات صريحة.

أضيفوا hook-delete-policy لإزالة Pods الاختبار المكتملة وعدم تركها تزدحم في مساحة الأسماء بين عمليات التشغيل.

وفقًا للعرف، توجد Pods الاختبار في templates/tests/، مما يحافظ على تنظيمها وفصلها عن ملفات manifest الخاصة بأحمالكم الفعلية.

في خط أنابيب، تثبّتون المخطط ثم تشغّلون helm test. ويؤدي فشل اختبار إلى فشل المهمة، فيكتشف عمليات النشر المعطوبة قبلكم.

كيف يحدّد Helm ما إذا كان اختبار Pod قد نجح؟

تعلّمتم أن helm test يشغّل Pods الاختبار التي تحمل التعليمة على إصدار قيد التشغيل، ويقيّمها من خلال رمز الخروج، ويندمج بسلاسة مع CI. 🎉