Go test प्रोजेक्ट के सभी टेस्ट कैसे चलाता है: अंदरूनी विश्लेषण

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

Go प्रोजेक्ट में सभी टेस्ट कैसे चलाएं और "अंदरूनी" क्या होता है?

\n

हर Go डेवलपर ने कम से कम एक बार टर्मिनल में जादुई कमांड go test ./... टाइप किया होगा और हरी टिकों को स्क्रीन पर दौड़ते देखा होगा। लेकिन क्या आपने कभी सोचा है कि इस समय वास्तव में क्या होता है? टेस्ट इस तरह क्यों चलते हैं, न कि किसी और तरह? और कभी-कभी go test आपके नए टेस्ट को चुपचाप क्यों छोड़ देता है?

\n

इस लेख में हम न केवल Stack Overflow पर लोकप्रिय प्रश्न का उत्तर देंगे (जहाँ इसके हज़ारों व्यूज़ हैं), बल्कि Go कंपाइलर के अंदर झाँकेंगे और जानेंगे कि परीक्षण तंत्र कैसे काम करता है। चलिए शुरू करते हैं!

\n\n

go test ./... जादू क्यों है?

\n

आइए मूल बातों से शुरू करें। बिना आर्गुमेंट के go test कमांड केवल वर्तमान पैकेज में टेस्ट चलाती है। लेकिन अगर आपके प्रोजेक्ट में दर्जनों पैकेज हैं (और वास्तविक प्रोडक्शन में ऐसा ही होता है), तो मैन्युअल रूप से उन्हें चलाना मध्ययुगीन यातना के समान है। यहाँ ./... मदद के लिए आता है।

\n

यह पैटर्न का अर्थ है: "वर्तमान निर्देशिका से शुरू करके सभी पैकेजों को रिकर्सिव रूप से खोजें"। Go निर्देशिका ट्री को पार करता है, vendor और मॉड्यूल को अनदेखा करता है, और सभी पैकेजों की सूची बनाता है। उनमें से प्रत्येक के लिए, यह go test का एक अलग इंस्टेंस चलाता है।

\n

लेकिन क्या होगा यदि आप केवल विशिष्ट निर्देशिकाओं में टेस्ट चलाना चाहते हैं? उदाहरण के लिए, केवल ./internal/... में? यह उसी तरह काम करता है: go test ./internal/...।

\n

महत्वपूर्ण: यदि आप Go Modules का उपयोग कर रहे हैं (Go 1.16+ के साथ यह मानक है), तो ./... केवल वर्तमान मॉड्यूल के भीतर काम करता है। वर्कस्पेस में सभी मॉड्यूल का परीक्षण करने के लिए, आपको प्रत्येक में go test ./... का उपयोग करना होगा या go.work कॉन्फ़िगर करना होगा।

\n\n

go test के संदर्भ में 'पैकेज' क्या है?

\n

Go पैकेज की अवधारणा पर काम करता है - एक ही निर्देशिका में .go फ़ाइलों का समूह। टेस्ट फ़ाइलें (प्रत्यय _test.go के साथ) भी पैकेज का हिस्सा मानी जाती हैं, लेकिन अलग से कंपाइल की जाती हैं। जब आप go test चलाते हैं, Go एक टेस्ट बाइनरी कंपाइल करता है जिसमें शामिल होता है:

\n
    \n
  • पैकेज का स्रोत कोड (लेकिन केवल वही जो टेस्ट में उपयोग होता है)
  • \n
  • टेस्ट का कोड स्वयं
  • \n
  • चलाने और रिपोर्ट करने के लिए एक विशेष रनटाइम रैपर
  • \n
\n

यह बाइनरी चलती है, टेस्ट निष्पादित करती है और परिणाम आउटपुट करती है। पूरी प्रक्रिया प्रत्येक पैकेज के लिए अलग होती है।

\n\n

Go कैसे तय करता है कि कौन से टेस्ट चलाने हैं?

\n

जब आप go test ./... लिखते हैं, Go निम्नलिखित चरण निष्पादित करता है:

\n
    \n
  1. फ़ाइल सिस्टम ट्रैवर्सल - Go उन सभी निर्देशिकाओं को ढूंढता है जिनमें .go फ़ाइलें हैं।
  2. \n
  3. फ़िल्टरिंग - vendor, testdata और छिपी हुई फ़ोल्डर (. से शुरू होने वाली) को अनदेखा किया जाता है।
  4. \n
  5. कंपाइलेशन - प्रत्येक पैकेज के लिए एक अस्थायी बाइनरी बनाई जाती है।
  6. \n
  7. निष्पादन - बाइनरी चलाई जाती है, परिणाम एकत्र किए जाते हैं।
  8. \n
  9. कैशिंग - यदि कोड नहीं बदला है, Go कैश का उपयोग करता है और (cached) दिखाता है।
  10. \n
\n

अंतिम बिंदु आश्चर्य का एक सामान्य कारण है। आपने टेस्ट बदला, go test ./... चलाया, और यह 'ok (cached)' कहता है। क्यों? क्योंकि Go इनपुट फ़ाइलों के हैश के आधार पर परिणाम कैश करता है। यदि आपने केवल एक टिप्पणी या अप्रयुक्त इम्पोर्ट बदला है, तो हैश नहीं बदलता, और टेस्ट पुनः नहीं चलता।

\n

टिप: कैश को जबरन रीसेट करने के लिए कमांड go clean -testcache का उपयोग करें। या फ्लैग -count=1 का उपयोग करें, जो Go को कैश को अनदेखा करने के लिए मजबूर करता है: go test -count=1 ./...।

\n\n

समानांतरता: टेस्ट हमेशा तेज़ क्यों नहीं होते?

\n

डिफ़ॉल्ट रूप से, go test एक पैकेज के भीतर टेस्ट को क्रमिक रूप से चलाता है। लेकिन पैकेजों के बीच - समानांतर! एक साथ चलने वाले पैकेजों की संख्या फ्लैग -p द्वारा निर्धारित की जाती है (डिफ़ॉल्ट रूप से CPU की संख्या के बराबर)।

\n

यह अच्छा लगता है, लेकिन एक बारीकी है: य

ब्लॉग

पुस्तक अनुशंसाएँ