कोडिंग साक्षात्कार: टिकाऊ परीक्षण आर्टिफ़ैक्ट्स के लिए आप Go 1.26 ArtifactDir का उपयोग कैसे करेंगे?

सवाल और दायरा

एक Go सेवा में रुक-रुक कर यूनिट, बेंचमार्क और फ़ज़ विफलताएं आती हैं। डेवलपर्स सफल CI रन को प्रदूषित किए बिना या समानांतर परीक्षणों को एक-दूसरे पर ओवरराइट करने की अनुमति दिए बिना अनुरोध नमूने, प्रदर्शन सारांश और डिबग डंप चाहते हैं। Go 1.26 testing.T.ArtifactDir, testing.B.ArtifactDir, और testing.F.ArtifactDir का उपयोग करके, एक आर्टिफ़ैक्ट नीति डिज़ाइन करें।

go test -artifacts के साथ, Go 1.26 आउटपुट डायरेक्टरी के तहत एक स्थायी डायरेक्टरी लौटाता है; इसके बिना, लौटाई गई अस्थायी डायरेक्टरी को परीक्षण के बाद हटा दिया जाता है। साक्ष्य लिखने वाले कोड को उसे बनाए रखने के निर्णय से अलग करें, और परीक्षण ढांचे को डायरेक्टरी जीवनचक्र को नियंत्रित करने दें।

संदर्भ और सीमाएं

Go परीक्षण कोड, संगामिति अलगाव, CI संग्रह, और संवेदनशील डेटा पर ध्यान केंद्रित करें। CI प्लेटफ़ॉर्म अपलोड, अनुमतियाँ, प्रतिधारण और ऑब्जेक्ट स्टोरेज प्रदान करता है; विफलता ट्रिगर, नामकरण, आकार सीमाएं, रिडक्शन, और पुनः प्रयास सीमाओं का उल्लेख करें।

साक्षात्कारकर्ता क्या परीक्षण करता है

• क्या आप T, B, और F संदर्भों के लिए आर्टिफ़ैक्ट डायरेक्टरीज़ में अंतर करते हैं।
• क्या विफल परीक्षण सफल रनों को स्थायी शोर में बदले बिना साक्ष्य बनाए रखते हैं।
• क्या आप t.Parallel, सबटेस्ट, बेंचमार्क लूप और फ़ज़ रीप्ले नामकरण को संभालते हैं।
• क्या फ़ाइलें पुनः प्रयास योग्य, सीमित, संग्रहणीय और किसी कमिट तथा परीक्षण नाम के लिए ट्रेस करने योग्य हैं।
• क्या टोकन, उपयोगकर्ता डेटा, निजी URL और कोर डंप सार्वजनिक CI आर्टिफ़ैक्ट्स से बाहर रखे गए हैं।

30-सेकंड का उत्तर

“प्रत्येक परीक्षण को अपनी डायरेक्टरी ArtifactDir से मिलती है; फ़ाइल नाम अनुमानित कार्यक्षेत्र पथों के बजाय परीक्षण पथ, रन ID और ईवेंट अनुक्रम का उपयोग करते हैं। कोड विफलता, सीमा उल्लंघन, या स्पष्ट डायग्नोस्टिक्स पर प्रमुख साक्ष्य लिखता है। CI go test -artifacts को सक्षम करता है और डायरेक्टरी को संग्रहीत करता है, जबकि स्थानीय डिफ़ॉल्ट एक अस्थायी डायरेक्टरी का उपयोग करते हैं जिसे साफ़ कर दिया जाता है। राइट्स बाइट और गणना सीमाओं के साथ एक अस्थायी फ़ाइल और नाम बदलने (रीनेम) का उपयोग करते हैं। एक मैनिफ़ेस्ट कमिट, पैकेज, परीक्षण, प्लेटफ़ॉर्म, हैश और रिडक्शन स्थिति को लिंक करता है; अपलोड विफलता मूल परीक्षण परिणाम को बदले बिना अलर्ट करती है।”

चरण-दर-चरण समाधान

1. एक आर्टिफ़ैक्ट प्रविष्टि बिंदु का उपयोग करें। एक परीक्षण *testing.T, *testing.B, या *testing.F प्राप्त करता है और इसके संबंधित ArtifactDir को कॉल करता है। परीक्षण लॉजिक में os.TempDir, कार्यशील डायरेक्टरी, या किसी निजी CI पथ को हार्ड-कोड न करें।

1. प्रतिधारण को लिखने से अलग करें। परीक्षण कोड विफलता से पहले या बाद में लिख सकता है, लेकिन दृढ़ता केवल तभी अपेक्षित होती है जब go test -artifacts सक्षम हो। डिफ़ॉल्ट रन एक अस्थायी डायरेक्टरी का उपयोग करते हैं जिसे साफ़ कर दिया जाता है; CI स्पष्ट रूप से आर्टिफ़ैक्ट्स को सक्षम करता है और उन्हें अपलोड करता है।

1. समवर्ती नाम डिज़ाइन करें। पैकेज, परीक्षण, रन ID, सबटेस्ट पथ और एक मोनोटोनिक अनुक्रम से एक लॉजिकल कुंजी बनाएं। विभाजक और गैर-मुद्रण योग्य वर्णों को सैनिटाइज़ करें। समानांतर इंस्टेंसेस को कभी भी एक निश्चित debug.json साझा नहीं करना चाहिए।

1. सीमाओं के साथ परमाणु रूप से (एटोमिकली) लिखें। आर्टिफ़ैक्ट डायरेक्टरी में एक अस्थायी फ़ाइल बनाएं, इसे सफलतापूर्वक बंद करें, फिर इसका नाम बदलें। प्रति-फ़ाइल, प्रति-परीक्षण, और प्रति-रन बाइट और गणना सीमाएं लागू करें; ओवरफ़्लो रनर को समाप्त करने के बजाय एक सारांश उत्पन्न करते हैं।

func writeArtifact(t *testing.T, name string, data []byte) {
    t.Helper()
    dir := t.ArtifactDir()
    path := filepath.Join(dir, safeName(name)+".json")
    tmp, err := os.CreateTemp(dir, ".partial-")
    if err != nil { t.Fatalf("create artifact: %v", err) }
    defer tmp.Close()
    if _, err := tmp.Write(data); err != nil { t.Fatalf("write artifact: %v", err) }
    if err := tmp.Close(); err != nil { t.Fatalf("close artifact: %v", err) }
    if err := os.Rename(tmp.Name(), path); err != nil { t.Fatalf("publish artifact: %v", err) }
}

उदाहरण आकार जांच, रिडक्शन और पोर्टेबल फ़ाइल नाम हैंडलिंग को छोड़ देता है; प्रोडक्शन कोड को इन्हें साझा परीक्षण बाधाएं बनाना चाहिए।

1. विफलता या सीमाओं पर ट्रिगर करें। विफल परीक्षण एक न्यूनतम पुनरुत्पादक, अनुरोध सारांश, ट्रेस पहचानकर्ता और पर्यावरण सारांश बनाए रखते हैं। बेंचमार्क केवल रिग्रेशन सीमा या स्पष्ट डायग्नोस्टिक मोड पर प्रोफ़ाइल या नमूने सहेजते हैं। फ़ज़ परीक्षण पूर्ण संवेदनशील अनुरोध के बजाय एक रीप्ले करने योग्य बीज (सीड) और एक संशोधित (रिडक्टेड), सीमित इनपुट सहेजते हैं।

1. CI आर्टिफ़ैक्ट्स को अनुक्रमित करें। कमिट SHA, पैकेज, परीक्षण, Go संस्करण, OS/आर्किटेक्चर, सापेक्ष पथ, आकार, हैश और रिडक्शन स्थिति युक्त एक मैनिफ़ेस्ट उत्सर्जित करें। रन ID द्वारा अपलोड को अलग करें। एक अपलोड विफलता चेतावनी देती है लेकिन असफल दावे को पास में नहीं बदलना चाहिए।

1. सुरक्षित करें और साफ़ करें। लिखने से पहले टोकन, कुकीज़, ऑथराइजेशन हेडर, व्यक्तिगत डेटा और निजी होस्टनाम हटा दें; डिफ़ॉल्ट रूप से कोर डंप अक्षम करें। न्यूनतम-विशेषाधिकार प्राप्त रीड और स्वचालित समाप्ति के साथ लघु प्रतिधारण का उपयोग करें। डाउनलोड के लिए अभी भी सामग्री-स्तरीय समीक्षा की आवश्यकता होती है।

1. जीवनचक्र का परीक्षण करें। एक असफल सबटेस्ट, एक समानांतर सबटेस्ट, एक go test -artifacts रन, और एक डिफ़ॉल्ट रन को कवर करें। सफल क्लीनअप, अनुक्रमित करने योग्य विफलता साक्ष्य, विशिष्ट पुनः प्रयास ID, और अपलोड बाधित होने पर स्थानीय साक्ष्य के संरक्षण को सत्यापित करें।

मॉडल उत्तर

सभी डायग्नोस्टिक फ़ाइलें T, B, या F ArtifactDir से उत्पन्न होनी चाहिए; परीक्षण लॉजिक को भौतिक पथ का ज्ञान नहीं होना चाहिए। दृढ़ता go test -artifacts द्वारा नियंत्रित होती है: CI इसे सक्षम और संग्रहीत करता है, जबकि स्थानीय रन एक अस्थायी डायरेक्टरी का उपयोग करते हैं जिसे साफ़ कर दिया जाता है। समानांतर टकरावों को रोकने के लिए नामों में पैकेज, परीक्षण, सबटेस्ट पथ, रन ID और अनुक्रम शामिल होते हैं। राइट्स बाइट और गणना सीमाओं के साथ एक अस्थायी फ़ाइल और रीनेम का उपयोग करते हैं।

विफल परीक्षण न्यूनतम इनपुट, अनुरोध सारांश और पर्यावरण डेटा बनाए रखते हैं। बेंचमार्क केवल तभी प्रोफ़ाइल बनाए रखते हैं जब कोई रिग्रेशन सीमा या स्पष्ट डायग्नोस्टिक मोड ट्रिगर होता है। फ़ज़ परीक्षण बीज और रीप्ले करने योग्य इनपुट बनाए रखते हैं। लिखने से पहले रिडक्शन होता है, और एक मैनिफ़ेस्ट कमिट, Go संस्करण, प्लेटफ़ॉर्म, हैश और आकार रिकॉर्ड करता है। अपलोड विफलता परीक्षण स्थिति को बदले बिना अलर्ट करती है। रिग्रेशन परीक्षण समानता, विफलता, डिफ़ॉल्ट अस्थायी भंडारण और स्थायी -artifacts भंडारण को कवर करते हैं।

सामान्य गलतियाँ

• गलती: ArtifactDir को स्थायी मानना → यह क्यों विफल होता है: डिफ़ॉल्ट अस्थायी डायरेक्टरी परीक्षण के बाद हटा दी जाती है → समाधान: CI में -artifacts सक्षम करें और संग्रह कॉन्फ़िगर करें।
• गलती: प्रत्येक समानांतर परीक्षण debug.json लिखता है → यह क्यों विफल होता है: फ़ाइलें ओवरराइट या इंटरलीव हो जाती हैं → समाधान: परीक्षण पथ, रन ID और अनुक्रम द्वारा नाम दें।
• गलती: विफलता पर एक पूर्ण HTTP अनुरोध अपलोड करना → यह क्यों विफल होता है: टोकन और व्यक्तिगत डेटा लीक हो जाते हैं → समाधान: रिडक्ट करें, सारांशित करें और प्रतिधारण को प्रतिबंधित करें।
• गलती: आर्टिफ़ैक्ट-राइट विफलता को परीक्षण पास करने देना → यह क्यों विफल होता है: विफलता साक्ष्य खो जाता है और पर्यावरण की समस्याएं छिप जाती हैं → समाधान: दावों को बदले बिना आवश्यक साक्ष्य पर विफल हों या स्पष्ट रूप से सचेत करें।
• गलती: प्रत्येक बेंचमार्क पुनरावृत्ति पर एक प्रोफ़ाइल लिखना → यह क्यों विफल होता है: आर्टिफ़ैक्ट की मात्रा और रनटाइम असीमित हो जाते हैं → समाधान: केवल रिग्रेशन सीमा या स्पष्ट डायग्नोस्टिक्स पर एकत्र करें।

अनुवर्ती प्रश्न और उत्तर

सीधे os.TempDir का उपयोग क्यों न करें?

ArtifactDir परीक्षण ढांचे और CI को जीवनचक्र निर्णयों का स्वामित्व लेने देता है, T, B और F को एक अनुबंध देता है, और निष्पादक-विशिष्ट पथों से बचाता है। os.TempDir डिस्पोजेबल सहायक फ़ाइलों के लिए ठीक है, आर्टिफ़ैक्ट प्रोटोकॉल के रूप में नहीं।

फ़ज़ आर्टिफ़ैक्ट्स रीप्ले करने योग्य कैसे बने रहते हैं?

Go संस्करण, पैकेज, परीक्षण, बीज, सीमित इनपुट का हैश, और आवश्यक पर्यावरण चर रिकॉर्ड करें। बड़े आकार के या संवेदनशील इनपुट के लिए, एक रिडक्टेड सारांश संग्रहीत करें और पूर्ण साक्ष्य केवल संरक्षित भंडारण में रखें।

एक बेंचमार्क को आर्टिफ़ैक्ट्स कब लिखना चाहिए?

बेंचमार्क समाप्त करें और पहले इसके बेसलाइन की तुलना करें। एक प्रोफ़ाइल केवल सीमा रिग्रेशन, स्पष्ट -bench डायग्नोस्टिक्स, या विफलता के बाद लिखें। नमूना गणना, CPU, अवधि, और कमिट शामिल करें ताकि सामान्य रन स्थायी संग्रह न बनें।

क्या आर्टिफ़ैक्ट अपलोड विफलता से CI विफल होना चाहिए?

एक असर्शन विफलता निश्चित रूप से विफल होनी चाहिए। क्या अपलोड विफलता रिलीज़ को रोकती है यह टीम के साक्ष्य स्तर पर निर्भर करता है, लेकिन इसे कम से कम सचेत करना चाहिए और एक स्थानीय पथ को संरक्षित करना चाहिए। नेटवर्क स्थिति को परीक्षण स्थिति के रूप में प्रच्छन्न नहीं किया जाना चाहिए।

आप पुनः प्रयासों (रीट्राई) को कैसे संभालते हैं?

प्रत्येक प्रयास के लिए एक विशिष्ट रन ID उत्पन्न करें। संग्रह कुंजियों में कमिट, प्लेटफ़ॉर्म, पैकेज, परीक्षण और प्रयास शामिल होते हैं। अनुक्रमणिकाएं प्रयासों को समूहीकृत कर सकती हैं, लेकिन कच्ची फ़ाइलें कभी भी एक दूसरे को ओवरराइट नहीं करती हैं; रिकॉर्ड करें कि क्या किसी पुनः प्रयास ने यादृच्छिक बीज का पुन: उपयोग किया है।

संदर्भ

• Go 1.26 रिलीज़ नोट्स (Go आधिकारिक)
• testing पैकेज (Go आधिकारिक)
• Go रिलीज़ इतिहास (Go आधिकारिक)

साक्षात्कार चेकलिस्ट

पहले ArtifactDir के जीवनचक्र की व्याख्या करें, फिर समवर्ती नामकरण, परमाणु राइट्स, विफलता ट्रिगर, मैनिफ़ेस्ट, रिडक्शन, CI संग्रह और रिग्रेशन परीक्षण जोड़ें।

एक-वाक्य का निष्कर्ष

ArtifactDir जीवनचक्र प्रविष्टि बिंदु प्रदान करता है; विश्वसनीय डायग्नोस्टिक्स को अभी भी अलगाव, सीमाओं, रिडक्शन, अनुक्रमण और रीप्ले करने योग्य साक्ष्य की आवश्यकता होती है।

अभ्यास जारी रखें

यदि CI फ़ज़, बेंचमार्क और एकीकरण परीक्षणों को एक साथ चलाता है, तो एक साझा मैनिफ़ेस्ट, कोटा और विफलता-प्राथमिकता अपलोड शेड्यूलर डिज़ाइन करें।