टेस्ट एक्ज़ीक्यूशन एनवायरमेंट की पूरी जानकारी.
बैकग्राउंड
Bazel BUILD लैंग्वेज में ऐसे नियम शामिल होते हैं जिनका इस्तेमाल, कई भाषाओं में अपने-आप होने वाले टेस्ट प्रोग्राम को तय करने के लिए किया जा सकता है.
टेस्ट, bazel test का इस्तेमाल करके चलाए जाते हैं.
उपयोगकर्ता, टेस्ट बाइनरी को सीधे तौर पर भी एक्ज़ीक्यूट कर सकते हैं. इसकी अनुमति है, लेकिन इसे बढ़ावा नहीं दिया जाता. ऐसा इसलिए, क्योंकि इस तरह का इनवोकेशन, यहां बताए गए निर्देशों का पालन नहीं करेगा.
टेस्ट हर्मेटिक होने चाहिए. इसका मतलब है कि उन्हें सिर्फ़ उन संसाधनों को ऐक्सेस करना चाहिए जिन पर उनकी निर्भरता है. अगर टेस्ट पूरी तरह से हर्मेटिक नहीं हैं, तो वे ऐसे नतीजे नहीं देते जिन्हें दोहराया जा सकता है. यह समस्या इन मामलों में गंभीर हो सकती है: गड़बड़ी करने वाले कोड का पता लगाना (यह तय करना कि किस बदलाव की वजह से टेस्ट काम नहीं कर रहा है), रिलीज़ इंजीनियरिंग की ऑडिट करने की क्षमता, और टेस्ट के संसाधनों को अलग करना. जैसे, अपने-आप टेस्ट करने वाले फ़्रेमवर्क को किसी सर्वर पर डीडीओएस नहीं करना चाहिए, क्योंकि कुछ टेस्ट उससे कम्यूनिकेट करते हैं.
मकसद
इस पेज का मकसद, Bazel टेस्ट के लिए रनटाइम एनवायरमेंट और अनुमानित व्यवहार को औपचारिक तौर पर सेट अप करना है. यह टेस्ट रनर और बिल्ड सिस्टम पर भी लागू होगा.
टेस्ट एनवायरमेंट की खास जानकारी से, टेस्ट लिखने वाले लोगों को यह पता चलता है कि उन्हें किस तरह के व्यवहार पर भरोसा नहीं करना चाहिए. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने से जुड़े बदलाव करने की ज़्यादा स्वतंत्रता मिलती है. इस स्पेसिफ़िकेशन में, कुछ ऐसी कमियों को दूर किया गया है जिनकी वजह से, फ़िलहाल कई टेस्ट पास हो जाते हैं. हालांकि, वे पूरी तरह से हर्मेटिक, डिटरमिनिस्टिक, और रीएंट्रेंट नहीं होते.
इस पेज का मकसद, नियमों के मुताबिक जानकारी देना और भरोसेमंद स्रोत से जानकारी देना है. अगर इस स्पेसिफ़िकेशन और टेस्ट रनर के लागू किए गए व्यवहार में अंतर है, तो स्पेसिफ़िकेशन को प्राथमिकता दी जाएगी.
प्रस्तावित स्पेसिफ़िकेशन
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" जैसे मुख्य शब्दों का मतलब, IETF RFC 2119 में दिए गए मतलब के हिसाब से होना चाहिए.
टेस्ट का मकसद
Bazel टेस्ट का मकसद, रिपॉज़िटरी में चेक की गई सोर्स फ़ाइलों की किसी प्रॉपर्टी की पुष्टि करना है. (इस पेज पर, "सोर्स फ़ाइलों" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी गई कोई भी अन्य चीज़ शामिल है.) एक उपयोगकर्ता, एक टेस्ट लिखता है. इससे यह पुष्टि की जाती है कि इनवेरिएंट को बनाए रखा गया है. अन्य उपयोगकर्ता, बाद में टेस्ट को एक्ज़ीक्यूट करते हैं. इससे यह पता चलता है कि इनवेरिएंट का उल्लंघन हुआ है या नहीं. अगर टेस्ट, सोर्स फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी अन्य वैरिएबल पर निर्भर करता है, तो इसकी वैल्यू कम हो जाती है. ऐसा इसलिए होता है, क्योंकि बाद के उपयोगकर्ताओं को यह पक्का नहीं हो सकता कि टेस्ट पास न होने पर, उनके बदलावों में कोई गड़बड़ी है.
इसलिए, टेस्ट का नतीजा सिर्फ़ इन बातों पर निर्भर होना चाहिए:
- सोर्स फ़ाइलें जिन पर टेस्ट निर्भर करता है
- बिल्ड सिस्टम के वे प्रॉडक्ट जिन पर टेस्ट की डिपेंडेंसी तय की गई है
- ऐसे संसाधन जिनके व्यवहार में, टेस्ट रनर के हिसाब से कोई बदलाव नहीं होता
फ़िलहाल, इस तरह के व्यवहार को रोकने के लिए कोई कार्रवाई नहीं की जाती. हालांकि, टेस्ट रनर के पास यह अधिकार होता है कि वे आने वाले समय में इस तरह के नियम लागू करें.
बिल्ड सिस्टम की भूमिका
टेस्ट के नियम, बाइनरी नियमों की तरह होते हैं. इनमें से हर नियम से, एक्ज़ीक्यूटेबल प्रोग्राम जनरेट होना चाहिए. कुछ भाषाओं के लिए, यह एक स्टब प्रोग्राम है. इसमें भाषा के हिसाब से बनाए गए हार्नेस को टेस्ट कोड के साथ जोड़ा जाता है. टेस्ट के नियमों से अन्य आउटपुट भी जनरेट होने चाहिए. टेस्ट रनर को टेस्ट के मुख्य एक्ज़ीक्यूटेबल के अलावा, runfiles का मेनिफ़ेस्ट और इनपुट फ़ाइलों की ज़रूरत होगी. ये फ़ाइलें, रनटाइम के दौरान टेस्ट के लिए उपलब्ध होनी चाहिए. साथ ही, उसे टेस्ट के टाइप, साइज़, और टैग के बारे में जानकारी की ज़रूरत पड़ सकती है.
बिल्ड सिस्टम, कोड और डेटा को डिलीवर करने के लिए रनफ़ाइल का इस्तेमाल कर सकता है. (इसका इस्तेमाल, हर टेस्ट बाइनरी को छोटा बनाने के लिए ऑप्टिमाइज़ेशन के तौर पर किया जा सकता है. इसके लिए, टेस्ट के बीच फ़ाइलें शेयर की जाती हैं. जैसे, डाइनैमिक लिंकिंग का इस्तेमाल करके.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई एक्ज़ीक्यूटेबल फ़ाइलें, टेस्ट रनर की ओर से उपलब्ध कराई गई runfiles इमेज के ज़रिए इन फ़ाइलों को लोड करें. इसके बजाय, सोर्स या आउटपुट ट्री में मौजूद ऐब्सलूट लोकेशन के हार्डकोड किए गए रेफ़रंस का इस्तेमाल न करें.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक प्रोग्राम होता है. इसे execve() की मदद से शुरू किया जा सकता है. टेस्ट को लागू करने के अन्य तरीके भी हो सकते हैं. उदाहरण के लिए, कोई आईडीई, Java टेस्ट को इन-प्रोसेस लागू करने की अनुमति दे सकता है. हालांकि, टेस्ट को स्टैंडअलोन प्रोसेस के तौर पर चलाने के नतीजे को आधिकारिक माना जाना चाहिए. अगर कोई टेस्ट प्रोसेस पूरी हो जाती है और एक्ज़िट कोड शून्य के साथ सामान्य रूप से बंद हो जाती है, तो इसका मतलब है कि टेस्ट पास हो गया है. किसी भी अन्य नतीजे को टेस्ट फ़ेल माना जाता है. खास तौर पर, stdout में PASS या FAIL स्ट्रिंग लिखने से, टेस्ट रनर पर कोई असर नहीं पड़ता.
अगर किसी टेस्ट को पूरा होने में बहुत ज़्यादा समय लगता है, वह संसाधन की किसी सीमा से ज़्यादा है या टेस्ट रनर को किसी अन्य वजह से प्रतिबंधित व्यवहार का पता चलता है, तो वह टेस्ट को बंद कर सकता है और रन को फ़ेल के तौर पर मार्क कर सकता है. टेस्ट प्रोसेस या उसके किसी भी हिस्से को सिग्नल भेजने के बाद, रनर को टेस्ट के पास होने की जानकारी नहीं देनी चाहिए.
पूरे टेस्ट टारगेट (अलग-अलग तरीकों या टेस्ट नहीं) को पूरा होने के लिए सीमित समय दिया जाता है. किसी टेस्ट के लिए समयसीमा, उसके timeout एट्रिब्यूट के आधार पर तय होती है. इसकी जानकारी इस टेबल में दी गई है:
| टाइम आउट | समयसीमा (सेकंड) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| अनंत | 3600 |
जिन टेस्ट में टाइम आउट के बारे में साफ़ तौर पर नहीं बताया गया है उनमें टेस्ट के size के आधार पर टाइम आउट तय किया जाता है. यह इस तरह से होता है:
| साइज़ | टाइम आउट का अनुमान लगाने वाला लेबल |
|---|---|
| छोटा | छोटा |
| मध्यम | मध्यम |
| बड़ा | लंबा |
| बहुत बड़ा | अनंत |
टाइम आउट की सेटिंग के बिना किए गए "बड़े" टेस्ट को पूरा होने में 900 सेकंड लगेंगे. "मीडियम" टेस्ट के लिए, "कम" टाइम आउट होने पर 60 सेकंड का समय दिया जाएगा.
timeout के उलट, size स्थानीय तौर पर टेस्ट चलाने के दौरान, अन्य संसाधनों (जैसे कि रैम) के ज़्यादा इस्तेमाल होने का अनुमान भी लगाता है. इसके बारे में सामान्य परिभाषाएं में बताया गया है.
size और timeout लेबल के सभी कॉम्बिनेशन कानूनी तौर पर मान्य हैं. इसलिए, "बहुत ज़्यादा" टेस्ट के लिए "कम" टाइम आउट का एलान किया जा सकता है. ऐसा माना जाता है कि यह बहुत कम समय में बहुत बुरी चीज़ें कर सकता है.
टेस्ट, टाइम आउट होने के बावजूद तुरंत नतीजे दिखा सकते हैं. अगर किसी टेस्ट में टाइम आउट की अवधि बहुत ज़्यादा है, तो उस पर जुर्माना नहीं लगाया जाता. हालांकि, चेतावनी दी जा सकती है: आपको आम तौर पर टाइम आउट की अवधि को उतना कम रखना चाहिए जितना हो सके, ताकि टेस्ट में कोई गड़बड़ी न हो.
अगर आपको पता है कि कुछ स्थितियों में टेस्ट धीमा चलता है, तो --test_timeout Bazel फ़्लैग का इस्तेमाल करके, टेस्ट के टाइमआउट को बदला जा सकता है. --test_timeout वैल्यू, सेकंड में होती हैं. उदाहरण के लिए, --test_timeout=120 टेस्ट के लिए टाइम आउट की अवधि को दो मिनट पर सेट करता है.
टेस्ट के टाइम आउट होने की कम सीमा भी सुझाई गई है. यह सीमा इस तरह है:
| टाइम आउट | कम से कम समय (सेकंड) |
|---|---|
| छोटा | 0 |
| मध्यम | 30 |
| लंबा | 300 |
| अनंत | 900 |
उदाहरण के लिए, अगर "सामान्य" टेस्ट 5.5 सेकंड में पूरा हो जाता है, तो timeout =
"short" या size = "small" को सेट करें. bazel --test_verbose_timeout_warnings कमांड-लाइन विकल्प का इस्तेमाल करने पर, उन टेस्ट के बारे में पता चलेगा जिनका साइज़ बहुत बड़ा है.
टेस्ट के साइज़ और टाइमआउट, BUILD फ़ाइल में यहां दिए गए स्पेसिफ़िकेशन के मुताबिक तय किए जाते हैं. अगर इसकी वैल्यू नहीं दी जाती है, तो टेस्ट का साइज़ डिफ़ॉल्ट रूप से "मीडियम" पर सेट हो जाएगा.
अगर किसी टेस्ट की मुख्य प्रोसेस बंद हो जाती है, लेकिन उसकी कुछ चाइल्ड प्रोसेस अब भी चल रही हैं, तो टेस्ट रनर को रन पूरा होने का स्टेटस देना चाहिए. साथ ही, मुख्य प्रोसेस से मिले एग्ज़िट कोड के आधार पर, उसे पास या फ़ेल के तौर पर मार्क करना चाहिए. टेस्ट रनर, किसी भी अनचाही प्रोसेस को बंद कर सकता है. टेस्ट में इस तरह से प्रोसेस लीक नहीं होनी चाहिए.
टेस्ट शार्डिंग
टेस्ट शार्डिंग की मदद से, टेस्ट को पैरलल किया जा सकता है. टेस्ट शार्डिंग की सुविधा चालू करने के लिए, --test_sharding_strategy और shard_count देखें. शार्डिंग की सुविधा चालू होने पर, टेस्ट रनर को हर शार्ड के लिए एक बार लॉन्च किया जाता है. एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS, शार्ड की संख्या है. वहीं, TEST_SHARD_INDEX, शार्ड इंडेक्स है, जो 0 से शुरू होता है. रनर इस जानकारी का इस्तेमाल करके यह चुनते हैं कि कौनसे टेस्ट चलाने हैं. उदाहरण के लिए, राउंड-रॉबिन रणनीति का इस्तेमाल करना. सभी टेस्ट रनर, शार्डिंग की सुविधा के साथ काम नहीं करते. अगर कोई रनर शार्डिंग की सुविधा के साथ काम करता है, तो उसे TEST_SHARD_STATUS_FILE में बताई गई फ़ाइल में पिछली बार बदलाव करने की तारीख को बनाना या अपडेट करना होगा. अगर --incompatible_check_sharding_support चालू है, तो Bazel, टेस्ट को कई हिस्सों में बांटने पर उसे पूरा नहीं कर पाएगा.
शुरुआती शर्तें
टेस्ट को लागू करते समय, टेस्ट रनर को कुछ शुरुआती शर्तें पूरी करनी होंगी.
टेस्ट रनर को हर टेस्ट को argv[0] में टेस्ट एक्ज़ीक्यूटेबल के पाथ के साथ शुरू करना होगा. यह पाथ, टेस्ट की मौजूदा डायरेक्ट्री के हिसाब से होना चाहिए. साथ ही, यह रनफ़ाइल ट्री के नीचे होना चाहिए. इसके बारे में यहां बताया गया है. टेस्ट रनर को किसी टेस्ट में कोई अन्य आर्ग्युमेंट पास नहीं करना चाहिए, जब तक कि उपयोगकर्ता साफ़ तौर पर ऐसा करने का अनुरोध न करे.
शुरुआती एनवायरमेंट ब्लॉक इस तरह से बनाया जाएगा:
| वैरिएबल | मान | स्थिति |
|---|---|---|
HOME |
$TEST_TMPDIR की वैल्यू |
सुझाया गया |
LANG |
unset | आवश्यक |
LANGUAGE |
unset | आवश्यक |
LC_ALL |
unset | आवश्यक |
LC_COLLATE |
unset | आवश्यक |
LC_CTYPE |
unset | आवश्यक |
LC_MESSAGES |
unset | आवश्यक |
LC_MONETARY |
unset | आवश्यक |
LC_NUMERIC |
unset | आवश्यक |
LC_TIME |
unset | आवश्यक |
LD_LIBRARY_PATH |
शेयर की गई लाइब्रेरी वाली डायरेक्ट्री की कोलन लगाकर अलग की गई सूची | ज़रूरी नहीं |
JAVA_RUNFILES |
$TEST_SRCDIR की वैल्यू |
बंद किया गया |
LOGNAME |
$USER की वैल्यू |
आवश्यक |
PATH |
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. |
सुझाया गया |
PWD |
$TEST_SRCDIR/workspace-name |
सुझाया गया |
SHLVL |
2 |
सुझाया गया |
TEST_INFRASTRUCTURE_FAILURE_FILE |
लिखने की अनुमति वाली डायरेक्ट्री में मौजूद किसी निजी फ़ाइल का पूरा पाथ (इस फ़ाइल का इस्तेमाल सिर्फ़ टेस्टिंग इन्फ़्रास्ट्रक्चर से होने वाली गड़बड़ियों की शिकायत करने के लिए किया जाना चाहिए. इसका इस्तेमाल, टेस्ट में होने वाली गड़बड़ियों की शिकायत करने के सामान्य तरीके के तौर पर नहीं किया जाना चाहिए. इस संदर्भ में, टेस्टिंग इन्फ़्रास्ट्रक्चर को ऐसे सिस्टम या लाइब्रेरी के तौर पर परिभाषित किया गया है जो टेस्ट के लिए खास नहीं हैं. हालांकि, ये ठीक से काम न करने की वजह से टेस्ट फ़ेल हो सकते हैं. पहली लाइन में, टेस्ट के बुनियादी ढांचे के उस कॉम्पोनेंट का नाम होता है जिसकी वजह से टेस्ट पूरा नहीं हो सका. दूसरी लाइन में, टेस्ट पूरा न हो पाने की वजह के बारे में ऐसी जानकारी होती है जिसे आसानी से समझा जा सकता है. अतिरिक्त लाइनों को अनदेखा कर दिया जाता है.) | ज़रूरी नहीं |
TEST_LOGSPLITTER_OUTPUT_FILE |
लिखने के लिए इस्तेमाल की जा सकने वाली डायरेक्ट्री में मौजूद किसी निजी फ़ाइल का ऐब्सलूट पाथ. इसका इस्तेमाल Logsplitter protobuffer लॉग लिखने के लिए किया जाता है | ज़रूरी नहीं |
TEST_PREMATURE_EXIT_FILE |
लिखने की अनुमति वाली डायरेक्ट्री में मौजूद किसी निजी फ़ाइल का ऐब्सलूट पाथ (इसका इस्तेमाल exit() को कॉल करने के लिए किया जाता है) |
ज़रूरी नहीं |
TEST_RANDOM_SEED |
अगर --runs_per_test विकल्प का इस्तेमाल किया जाता है, तो हर टेस्ट रन के लिए TEST_RANDOM_SEED को run number (1 से शुरू होने वाला) पर सेट किया जाता है. |
ज़रूरी नहीं |
TEST_RUN_NUMBER |
अगर --runs_per_test विकल्प का इस्तेमाल किया जाता है, तो हर टेस्ट रन के लिए TEST_RUN_NUMBER को run number (1 से शुरू होने वाला) पर सेट किया जाता है. |
ज़रूरी नहीं |
TEST_TARGET |
जांचे जा रहे टारगेट का नाम | ज़रूरी नहीं |
TEST_SIZE |
टेस्ट size |
ज़रूरी नहीं |
TEST_TIMEOUT |
जांच में timeout सेकंड लगते हैं |
ज़रूरी नहीं |
TEST_SHARD_INDEX |
अगर sharding का इस्तेमाल किया जाता है, तो शार्ड इंडेक्स |
ज़रूरी नहीं |
TEST_SHARD_STATUS_FILE |
sharding के साथ काम करने वाली फ़ाइल का पाथ |
ज़रूरी नहीं |
TEST_SRCDIR |
रनफ़ाइल ट्री के बेस का ऐब्सलूट पाथ | आवश्यक |
TEST_TOTAL_SHARDS |
total
shard count,
if sharding is used |
ज़रूरी नहीं |
TEST_TMPDIR |
निजी तौर पर लिखने के लिए डायरेक्ट्री का ऐब्सलूट पाथ | आवश्यक |
TEST_WORKSPACE |
लोकल रिपॉज़िटरी के वर्कस्पेस का नाम | ज़रूरी नहीं |
TEST_UNDECLARED_OUTPUTS_DIR |
ऐसी डायरेक्ट्री का ऐब्सलूट पाथ जिसमें लिखा जा सकता है. इसका इस्तेमाल, बिना बताए गए टेस्ट के आउटपुट लिखने के लिए किया जाता है. TEST_UNDECLARED_OUTPUTS_DIR डायरेक्ट्री में लिखी गई सभी फ़ाइलों को ज़िप किया जाएगा और उन्हें bazel-testlogs में मौजूद outputs.zip फ़ाइल में जोड़ दिया जाएगा. |
ज़रूरी नहीं |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR |
ऐसी डायरेक्ट्री का ऐब्सलूट पाथ जिसमें बदलाव किया जा सकता है. इसका इस्तेमाल, टेस्ट के ऐसे आउटपुट एनोटेशन .part और .pb फ़ाइलों को लिखने के लिए किया जाता है जिनके बारे में जानकारी नहीं दी गई है. |
ज़रूरी नहीं |
TEST_WARNINGS_OUTPUT_FILE |
लिखने के लिए उपलब्ध डायरेक्ट्री में मौजूद किसी निजी फ़ाइल का ऐब्सलूट पाथ. इसका इस्तेमाल, टेस्ट टारगेट से जुड़ी चेतावनियां लिखने के लिए किया जाता है | ज़रूरी नहीं |
TESTBRIDGE_TEST_ONLY |
अगर --test_filter की वैल्यू दी गई है, तो उसकी वैल्यू |
ज़रूरी नहीं |
TZ |
UTC |
आवश्यक |
USER |
getpwuid(getuid())->pw_name की वैल्यू |
आवश्यक |
XML_OUTPUT_FILE |
वह जगह जहां टेस्ट की कार्रवाइयों को, टेस्ट के नतीजे वाली एक्सएमएल आउटपुट फ़ाइल लिखनी चाहिए. ऐसा न करने पर, Bazel टेस्ट ऐक्शन के हिस्से के तौर पर, टेस्ट लॉग को रैप करने वाली डिफ़ॉल्ट एक्सएमएल आउटपुट फ़ाइल जनरेट करता है. एक्सएमएल स्कीमा, JUnit टेस्ट के नतीजे के स्कीमा पर आधारित है. | ज़रूरी नहीं |
BAZEL_TEST |
इससे पता चलता है कि टेस्ट एक्ज़ीक्यूटेबल को bazel test मैनेज कर रहा है |
आवश्यक |
ऐसा हो सकता है कि एनवायरमेंट में अन्य एंट्री भी मौजूद हों. जांचों में, ऊपर दी गई सूची में शामिल न किए गए किसी भी एनवायरमेंट वैरिएबल की मौजूदगी, गैर-मौजूदगी या वैल्यू पर निर्भर नहीं होना चाहिए.
शुरुआती वर्किंग डायरेक्ट्री $TEST_SRCDIR/$TEST_WORKSPACE होगी.
मौजूदा प्रोसेस आईडी, प्रोसेस ग्रुप आईडी, सेशन आईडी, और पैरंट प्रोसेस आईडी की जानकारी नहीं दी गई है. यह प्रोसेस, प्रोसेस ग्रुप लीडर या सेशन लीडर हो सकती है या नहीं भी हो सकती. इस प्रोसेस में कंट्रोलिंग टर्मिनल हो सकता है और नहीं भी. इस प्रोसेस में, शून्य या उससे ज़्यादा चाइल्ड प्रोसेस चल रही हो सकती हैं या उन्हें बंद किया जा सकता है. टेस्ट कोड को कंट्रोल मिलने पर, प्रोसेस में एक से ज़्यादा थ्रेड नहीं होनी चाहिए.
फ़ाइल डिस्क्रिप्टर 0 (stdin) को पढ़ने के लिए खोला जाएगा, लेकिन यह किससे जुड़ा है, यह नहीं बताया गया है. टेस्ट को इससे डेटा नहीं पढ़ना चाहिए. फ़ाइल डिस्क्रिप्टर 1 (stdout) और 2 (stderr) को लिखने के लिए खोला जाएगा. हालांकि, ये किससे अटैच हैं, यह नहीं बताया गया है. यह कोई टर्मिनल, पाइप, सामान्य फ़ाइल या कोई अन्य ऐसी चीज़ हो सकती है जिसमें वर्ण लिखे जा सकते हैं. ये खुली हुई फ़ाइल की टेबल में एक एंट्री शेयर कर सकते हैं
(इसका मतलब है कि ये स्वतंत्र रूप से नहीं खोज सकते). जांचों में, किसी अन्य खुली फ़ाइल के ब्यौरे शामिल नहीं होने चाहिए.
शुरुआती umask 022 या 027 होना चाहिए.
कोई अलार्म या इंटरवल टाइमर चालू नहीं होना चाहिए.
ब्लॉक किए गए सिग्नल का शुरुआती मास्क खाली होना चाहिए. सभी सिग्नल, डिफ़ॉल्ट ऐक्शन पर सेट हो जाएंगे.
संसाधन की शुरुआती सीमाएं, सॉफ़्ट और हार्ड, दोनों को इस तरह सेट किया जाना चाहिए:
| संसाधन | सीमा |
|---|---|
RLIMIT_AS |
अनलिमिटेड |
RLIMIT_CORE |
बताया नहीं गया |
RLIMIT_CPU |
अनलिमिटेड |
RLIMIT_DATA |
अनलिमिटेड |
RLIMIT_FSIZE |
अनलिमिटेड |
RLIMIT_LOCKS |
अनलिमिटेड |
RLIMIT_MEMLOCK |
अनलिमिटेड |
RLIMIT_MSGQUEUE |
बताया नहीं गया |
RLIMIT_NICE |
बताया नहीं गया |
RLIMIT_NOFILE |
कम से कम 1,024 |
RLIMIT_NPROC |
बताया नहीं गया |
RLIMIT_RSS |
अनलिमिटेड |
RLIMIT_RTPRIO |
बताया नहीं गया |
RLIMIT_SIGPENDING |
बताया नहीं गया |
RLIMIT_STACK |
असीमित या 2044 केबी <= rlim <= 8192 केबी |
times() से मिले शुरुआती प्रोसेस के समय और getrusage() से मिले संसाधन के इस्तेमाल की जानकारी नहीं दी गई है.
शेड्यूलिंग की शुरुआती नीति और प्राथमिकता के बारे में नहीं बताया गया है.
होस्ट सिस्टम की भूमिका
टेस्ट रनर के सीधे कंट्रोल में मौजूद उपयोगकर्ता के कॉन्टेक्स्ट के पहलुओं के अलावा, टेस्ट रन के मान्य होने के लिए, टेस्ट चलाने वाले ऑपरेटिंग सिस्टम को कुछ प्रॉपर्टी पूरी करनी होंगी.
फ़ाइल सिस्टम
ऐसा हो सकता है कि टेस्ट में देखी गई रूट डायरेक्ट्री, असली रूट डायरेक्ट्री न हो.
/proc को लगाया जाएगा.
सभी बिल्ड टूल, लोकल इंस्टॉलेशन के लिए इस्तेमाल किए गए /usr के ऐब्सलूट पाथ पर मौजूद होने चाहिए.
ऐसा हो सकता है कि /home से शुरू होने वाले पाथ उपलब्ध न हों. टेस्ट को ऐसे किसी भी पाथ को ऐक्सेस नहीं करना चाहिए.
/tmp में लिखा जा सकता है. हालांकि, टेस्ट में इन पाथ का इस्तेमाल नहीं किया जाना चाहिए.
जांचों में यह नहीं माना जाना चाहिए कि किसी कॉन्स्टेंट पाथ का इस्तेमाल सिर्फ़ उनके लिए किया जा सकता है.
टेस्ट में यह नहीं माना जाना चाहिए कि किसी भी माउंट किए गए फ़ाइल सिस्टम के लिए, ऐक्सेस टाइम चालू हैं.
उपयोगकर्ता और समूह
उपयोगकर्ता रूट, नोबडी, और यूनिटटेस्ट मौजूद होने चाहिए. रूट, नोबडी, और eng ग्रुप मौजूद होने चाहिए.
टेस्ट को नॉन-रूट उपयोगकर्ता के तौर पर एक्ज़ीक्यूट किया जाना चाहिए. असली और असरदार यूज़र आईडी एक जैसे होने चाहिए. इसी तरह, ग्रुप आईडी भी एक जैसे होने चाहिए. इसके अलावा, मौजूदा उपयोगकर्ता आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप का नाम नहीं बताया गया है. पूरक ग्रुप आईडी का सेट तय नहीं किया गया है.
मौजूदा उपयोगकर्ता आईडी और ग्रुप आईडी के नाम होने चाहिए. इन्हें getpwuid() और getgrgid() की मदद से वापस पाया जा सकता है. हालांकि, ऐसा हो सकता है कि पूरक ग्रुप आईडी के लिए यह ज़रूरी न हो.
मौजूदा उपयोगकर्ता के पास होम डायरेक्ट्री होनी चाहिए. ऐसा हो सकता है कि इसमें लिखा न जा सके. टेस्ट को इसमें लिखने की कोशिश नहीं करनी चाहिए.
नेटवर्किंग
होस्टनाम नहीं बताया गया है. इसमें बिंदु हो सकता है और नहीं भी. होस्टनेम को हल करने पर, मौजूदा होस्ट का आईपी पता मिलना चाहिए. पहले डॉट के बाद होस्टनेम को छोटा करने की सुविधा भी काम करनी चाहिए. होस्टनेम localhost को हल किया जाना चाहिए.
अन्य संसाधन
टेस्ट को कम से कम एक सीपीयू कोर दिया जाता है. अन्य विकल्प उपलब्ध हो सकते हैं, लेकिन इसकी कोई गारंटी नहीं है. इस कोर की परफ़ॉर्मेंस के अन्य पहलुओं के बारे में नहीं बताया गया है. टेस्ट के नियम में "cpu:n" टैग (जहां n एक पॉज़िटिव संख्या है) जोड़कर, सीपीयू कोर के लिए ज़्यादा से ज़्यादा संख्या में आरक्षण किया जा सकता है. अगर किसी मशीन में अनुरोध किए गए सीपीयू कोर से कम सीपीयू कोर हैं, तो भी Bazel टेस्ट चलाएगा. अगर किसी टेस्ट में शार्डिंग का इस्तेमाल किया जाता है, तो हर शार्ड के लिए, यहां बताए गए सीपीयू कोर की संख्या रिज़र्व की जाएगी.
टेस्ट से सबप्रोसेस बनाई जा सकती हैं, लेकिन प्रोसेस ग्रुप या सेशन नहीं.
किसी टेस्ट के लिए, इनपुट फ़ाइलों की संख्या सीमित होती है. इस सीमा में बदलाव किया जा सकता है. हालांकि, फ़िलहाल यह सीमा दस हज़ार से ज़्यादा इनपुट की है.
समय और तारीख
मौजूदा समय और तारीख की जानकारी नहीं दी गई है. सिस्टम के टाइमज़ोन की जानकारी नहीं दी गई है.
X Windows उपलब्ध हो भी सकता है और नहीं भी. जिन टेस्ट के लिए X सर्वर की ज़रूरत होती है उन्हें Xvfb शुरू करना चाहिए.
फ़ाइल सिस्टम के साथ इंटरैक्शन की जांच करना
टेस्ट एनवायरमेंट वैरिएबल में बताए गए सभी फ़ाइल पाथ, लोकल फ़ाइल सिस्टम में किसी जगह पर पॉइंट करते हैं. हालांकि, ऐसा तब तक होता है, जब तक कोई और फ़ाइल पाथ न बताया गया हो.
जांचों को सिर्फ़ उन डायरेक्ट्री में फ़ाइलें बनानी चाहिए जिन्हें $TEST_TMPDIR और $TEST_UNDECLARED_OUTPUTS_DIR (अगर सेट है) ने तय किया है.
शुरुआत में ये डायरेक्ट्री खाली होंगी.
टेस्ट में इन डायरेक्ट्री को हटाने, chmod करने या उनमें किसी तरह का बदलाव करने की कोशिश नहीं की जानी चाहिए.
ये डायरेक्ट्री, सिंबॉलिक लिंक हो सकती हैं.
$TEST_TMPDIR/. के फ़ाइल सिस्टम टाइप की जानकारी नहीं दी गई है.
टेस्ट, .part फ़ाइलें भी लिख सकते हैं. ऐसा $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR में, बिना बताए आउटपुट फ़ाइलों को एनोटेट करने के लिए किया जाता है.
कुछ मामलों में, टेस्ट को /tmp में फ़ाइलें बनाने के लिए मजबूर किया जा सकता है. उदाहरण के लिए, Unix डोमेन सॉकेट के लिए पाथ की लंबाई की सीमाएं आम तौर पर, सॉकेट को /tmp के तहत बनाने की ज़रूरत होती है. Bazel ऐसी फ़ाइलों को ट्रैक नहीं कर पाएगा. टेस्ट को खुद यह पक्का करना होगा कि वह हर्मेटिक है. साथ ही, उसे यूनीक पाथ का इस्तेमाल करना होगा, ताकि एक साथ चल रहे अन्य टेस्ट और नॉन-टेस्ट प्रोसेस से टकराव न हो. इसके अलावा, उसे /tmp में बनाई गई फ़ाइलों को मिटाना होगा.
कुछ लोकप्रिय टेस्टिंग फ़्रेमवर्क, जैसे कि JUnit4 TemporaryFolder या Go TempDir, /tmp के तहत अस्थायी डायरेक्ट्री बनाने के अपने तरीके हैं. इन टेस्टिंग फ़्रेमवर्क में, /tmp में मौजूद फ़ाइलों को हटाने की सुविधा शामिल होती है. इसलिए, इनका इस्तेमाल किया जा सकता है. भले ही, ये /tmp से बाहर की फ़ाइलें बनाते हों.TEST_TMPDIR
टेस्ट को runfiles मैकेनिज़्म के ज़रिए इनपुट ऐक्सेस करने चाहिए. इसके अलावा, उन्हें एक्ज़ीक्यूशन एनवायरमेंट के उन हिस्सों के ज़रिए भी इनपुट ऐक्सेस करने चाहिए जो खास तौर पर इनपुट फ़ाइलें उपलब्ध कराने के लिए बनाए गए हैं.
जांचों को, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं करना चाहिए. ये आउटपुट, उनके खुद के एक्ज़ीक्यूटेबल की जगह से अनुमानित पाथ पर होते हैं.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिंबॉलिक लिंक या दोनों शामिल हैं. रनफ़ाइल ट्री में, डायरेक्ट्री के लिए सिमलंक शामिल हो सकते हैं.
जांच में, ऐसे पाथ का इस्तेमाल नहीं किया जाना चाहिए जिनमें runfiles ट्री में .. कॉम्पोनेंट शामिल हों.
runfiles ट्री में मौजूद किसी भी डायरेक्ट्री, फ़ाइल या सिंबल लिंक (उन पाथ के साथ जो सिंबल लिंक को ट्रैवर्स करते हैं) को लिखा नहीं जाना चाहिए. (इसका मतलब है कि शुरुआती वर्किंग डायरेक्ट्री में लिखने की अनुमति नहीं होनी चाहिए.) जांचों में यह नहीं माना जाना चाहिए कि रनफ़ाइल का कोई भी हिस्सा लिखा जा सकता है या मौजूदा उपयोगकर्ता के पास उसका मालिकाना हक है. उदाहरण के लिए, chmod और chgrp फ़ेल हो सकते हैं.
टेस्ट के दौरान, रनफ़ाइल ट्री (इसमें सिमलंक से गुज़रने वाले पाथ भी शामिल हैं) में कोई बदलाव नहीं होना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में ऐसा कोई बदलाव नहीं होना चाहिए जिससे रनफ़ाइल ट्री में पाथ को हल करने के नतीजे पर असर पड़े.
जल्द बंद होने की समस्या का पता लगाने के लिए, टेस्ट शुरू होने पर TEST_PREMATURE_EXIT_FILE में बताई गई जगह पर एक फ़ाइल बना सकता है और बंद होने पर उसे हटा सकता है. अगर Bazel को टेस्ट पूरा होने पर फ़ाइल दिखती है, तो वह यह मान लेगा कि टेस्ट समय से पहले बंद हो गया है. साथ ही, वह इसे फ़ेल के तौर पर मार्क कर देगा.
एक्ज़ीक्यूशन प्लैटफ़ॉर्म
किसी टेस्ट ऐक्शन के लिए एक्ज़ीक्यूशन प्लैटफ़ॉर्म, टूलचेन रिज़ॉल्यूशन के ज़रिए तय किया जाता है. यह ठीक उसी तरह होता है जैसे किसी अन्य ऐक्शन के लिए किया जाता है. हर टेस्ट नियम में,
test exec group को डिफ़ॉल्ट रूप से तय किया जाता है. अगर इसे बदला नहीं जाता है, तो @bazel_tools//tools/test:default_test_toolchain_type पर टूलचेन की ज़रूरी शर्त लागू होती है.
इस तरह की टूलचेन में, प्रोवाइडर के तौर पर कोई डेटा नहीं होता. हालांकि, इनका इस्तेमाल टेस्ट ऐक्शन के एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर असर डालने के लिए किया जा सकता है.
Bazel, इस तरह की दो टूलचेन रजिस्टर करता है. अगर उपयोगकर्ता साफ़ तौर पर अपनी टूलचेन तय नहीं करते हैं, तो ये टूलचेन लागू हो जाती हैं::
अगर
--@bazel_tools//tools/test:incompatible_use_default_test_toolchainचालू है (डिफ़ॉल्ट), तो चालू टेस्ट टूलचेन@bazel_tools//tools/test:default_test_toolchainहै. इस टूलचेन को एक ऐसे प्लैटफ़ॉर्म की ज़रूरत होती है जो टेस्ट के नियम के टारगेट प्लैटफ़ॉर्म की सभी शर्तों को पूरा करता हो.खास तौर पर, टारगेट प्लैटफ़ॉर्म इस टूलचेन के साथ काम करता है, अगर इसे एक्ज़ीक्यूशन प्लैटफ़ॉर्म के तौर पर भी रजिस्टर किया गया हो. अगर ऐसा कोई प्लैटफ़ॉर्म नहीं मिलता है, तो टूलचेन रिज़ॉल्यूशन से जुड़ी गड़बड़ी की वजह से, टेस्ट का नियम लागू नहीं होता
अगर
--@bazel_tools//tools/test:incompatible_use_default_test_toolchainबंद है, तो चालू टेस्ट टूलचेन@bazel_tools//tools/test:legacy_test_toolchainहै. इस टूलचेन में कोई पाबंदी नहीं है. इसलिए, मैन्युअल तरीके से तय की गई exec पाबंदियों के बिना टेस्ट ऐक्शन, रजिस्टर किए गए पहले एक्ज़ीक्यूशन प्लैटफ़ॉर्म के लिए कॉन्फ़िगर किए जाते हैं.आम तौर पर, मल्टी-प्लैटफ़ॉर्म बिल्ड में ऐसा नहीं होना चाहिए. इसकी वजह यह है कि इससे कई तरह की समस्याएं हो सकती हैं. उदाहरण के लिए, Windows मशीन पर Linux के लिए बनाया गया टेस्ट बाइनरी, Windows पर एक्ज़ीक्यूट हो सकता है.
लेगसी सेटिंग के तौर पर, उम्मीद है कि यह विकल्प Bazel के आने वाले वर्शन में उपलब्ध नहीं होगा.
उपयोगकर्ता, इस तरह के टूलचेन के लिए अतिरिक्त टूलचेन रजिस्टर कर सकते हैं. इससे इस व्यवहार पर असर पड़ेगा. साथ ही, उनके टूलचेन को डिफ़ॉल्ट टूलचेन से ज़्यादा प्राथमिकता दी जाएगी. टेस्ट के नियम बनाने वाले लोग, टेस्ट टूलचेन का टाइप तय कर सकते हैं. साथ ही, इसके लिए डिफ़ॉल्ट टूलचेन रजिस्टर कर सकते हैं.
टैग के लिए नेमिंग कनवेंशन
जांच के नियमों में मौजूद कुछ टैग का खास मतलब होता है.
tags एट्रिब्यूट के बारे में Bazel Build Encyclopedia में भी जानकारी देखें.
| टैग | मतलब |
|---|---|
exclusive |
एक ही समय पर कोई दूसरा टेस्ट न चलाएं |
external |
टेस्ट में बाहरी डिपेंडेंसी है; टेस्ट कैश मेमोरी बंद करें |
large |
test_suite कन्वेंशन; बड़े टेस्ट का सुइट |
manual * |
वाइल्डकार्ड टारगेट पैटर्न में टेस्ट टारगेट शामिल न करें. जैसे, :..., :* या :all |
medium |
test_suite कन्वेंशन; मीडियम टेस्ट का सुइट |
small |
test_suite कन्वेंशन; छोटे टेस्ट का सुइट |
smoke |
test_suite कन्वेंशन का पालन करता है. इसका मतलब है कि इसे वर्शन कंट्रोल सिस्टम में कोड में किए गए बदलावों को सेव करने से पहले चलाना चाहिए |
Runfiles
यहां मान लें कि //foo/bar:unittest लेबल वाला *_binary() नियम है. यह नियम, //deps/server:server लेबल वाले नियम पर रनटाइम के दौरान निर्भर करता है.
जगह
किसी टारगेट //foo/bar:unittest के लिए रनफ़ाइल डायरेक्ट्री, $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles डायरेक्ट्री होती है. इस पाथ को runfiles_dir कहा जाता है.
डिपेंडेंसी
runfiles डायरेक्ट्री को *_binary() नियम की कंपाइल-टाइम डिपेंडेंसी के तौर पर एलान किया गया है. runfiles डायरेक्ट्री, BUILD फ़ाइलों के उस सेट पर निर्भर करती है जो *_binary() नियम या उसकी कंपाइल-टाइम या रन-टाइम डिपेंडेंसी को प्रभावित करती हैं. सोर्स फ़ाइलों में बदलाव करने से, रनफ़ाइल डायरेक्ट्री के स्ट्रक्चर पर कोई असर नहीं पड़ता. इसलिए, इससे किसी भी तरह की रीबिल्डिंग ट्रिगर नहीं होती.
सामग्री
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल होती हैं:
- रन-टाइम डिपेंडेंसी के लिए सिंबल लिंक:
*_binary()नियम की रन-टाइम डिपेंडेंसी वाले हर OutputFile और CommandRule को रनफ़ाइल डायरेक्ट्री में एक सिंबल लिंक के तौर पर दिखाया जाता है. सिंबलिक लिंक का नाम$(WORKSPACE)/package_name/rule_nameहै. उदाहरण के लिए, server के लिए सिंबल लिंक का नाम$(WORKSPACE)/deps/server/serverहोगा और पूरा पाथ$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverहोगा. सिमलिंक का डेस्टिनेशन, OutputFile या CommandRule का OutputFileName() होता है. इसे ऐब्सलूट पाथ के तौर पर दिखाया जाता है. इसलिए, सिंबॉलिक लिंक का डेस्टिनेशन$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकता है.