helm test Cases लिखना

lint और template फ़ाइलों की जाँच करते हैं, लेकिन helm test आपके क्लस्टर में पहले से चल रही रिलीज़ की जाँच करता है। यह साबित करता है कि ऐप वास्तव में काम करता है। ✅

Helm परीक्षण आपके चार्ट की templates डायरेक्टरी में परिभाषित एक Pod होता है। Helm इसे आवश्यकता पड़ने पर चलाता है और उसके एग्ज़िट कोड से सफलता का निर्णय करता है।

किसी Pod को परीक्षण के रूप में चिह्नित करने के लिए helm.sh/hook: test एनोटेशन जोड़ें। इसके बाद Helm इंस्टॉल के दौरान उसे छोड़ देता है और केवल कहने पर चलाता है।

एक सामान्य परीक्षण में busybox जैसी छोटी इमेज wget का उपयोग करके यह पुष्टि करती है कि आपकी सर्विस अपने पोर्ट पर प्रतिक्रिया दे रही है।

यदि परीक्षण Pod 0 के साथ बंद होता है, तो परीक्षण सफल होता है। शून्य के अलावा कोई भी एग्ज़िट कोड उसे विफल चिह्नित करता है, ठीक शेल कमांड की तरह।

इंस्टॉल करने के बाद, रिलीज़ नाम के साथ helm test चलाएँ। Helm परीक्षण Pods बनाता है, प्रतीक्षा करता है और हर परिणाम की रिपोर्ट करता है।

हर परीक्षण Pod का परिणाम स्ट्रीम करने के लिए --logs जोड़ें। इससे विफलता केवल यह बताने के बजाय कि वह विफल हुई, यह भी बताएगी कि क्या गलत हुआ।

इंस्टॉल के दौरान परीक्षण अपने-आप नहीं चलते। आप उन्हें स्वयं शुरू करते हैं, जिससे इंस्टॉल तेज़ रहते हैं और परीक्षण स्पष्ट रूप से शुरू किए गए होते हैं।

hook-delete-policy जोड़ें, ताकि पूरे हो चुके परीक्षण Pods हट जाएँ और रन के बीच आपका नेमस्पेस अव्यवस्थित न हो।

परंपरा के अनुसार परीक्षण Pods templates/tests/ में रखे जाते हैं। इससे वे व्यवस्थित रहते हैं और आपके वास्तविक वर्कलोड मेनिफेस्ट से अलग रहते हैं।

एक पाइपलाइन में आप चार्ट इंस्टॉल करते हैं और फिर helm test चलाते हैं। विफल परीक्षण जॉब को विफल कर देता है और उपयोगकर्ताओं के सामने आने से पहले खराब डिप्लॉयमेंट पकड़ लेता है।

आपने सीखा कि helm test लाइव रिलीज़ के विरुद्ध एनोटेशन वाले परीक्षण Pods चलाता है, उनके एग्ज़िट कोड से निर्णय करता है और CI में आसानी से शामिल किया जा सकता है। 🎉