टेस्ट एक्ज़ीक्यूशन एनवायरमेंट की पूरी जानकारी.
बैकग्राउंड
Bazel BUILD लैंग्वेज में ऐसे नियम शामिल होते हैं जिनका इस्तेमाल, कई भाषाओं में अपने-आप होने वाले टेस्ट प्रोग्राम को तय करने के लिए किया जा सकता है.
टेस्ट, bazel test का इस्तेमाल करके चलाए जाते हैं.
उपयोगकर्ता, टेस्ट बाइनरी को सीधे तौर पर भी एक्ज़ीक्यूट कर सकते हैं. इसकी अनुमति है, लेकिन इसे बढ़ावा नहीं दिया जाता. ऐसा इसलिए, क्योंकि इस तरह के इनवोकेशन से यहां बताई गई ज़रूरी शर्तों का पालन नहीं होगा.
टेस्ट हर्मेटिक होने चाहिए. इसका मतलब है कि उन्हें सिर्फ़ उन संसाधनों को ऐक्सेस करना चाहिए जिन पर उनकी निर्भरता है. अगर टेस्ट पूरी तरह से हर्मेटिक नहीं हैं, तो वे ऐसे नतीजे नहीं देते जिन्हें दोहराया जा सके. यह समस्या इन मामलों में गंभीर हो सकती है: गड़बड़ी करने वाले कोड का पता लगाना (यह तय करना कि किस बदलाव की वजह से टेस्ट काम नहीं कर रहा है), रिलीज़ इंजीनियरिंग की ऑडिट करने की क्षमता, और टेस्ट के संसाधनों को अलग करना. जैसे, अपने-आप टेस्ट करने वाले फ़्रेमवर्क को किसी सर्वर पर डीडीओएस नहीं करना चाहिए, क्योंकि कुछ टेस्ट उससे कम्यूनिकेट करते हैं.
मकसद
इस पेज का मकसद, Bazel टेस्ट के लिए रनटाइम एनवायरमेंट और अनुमानित व्यवहार को औपचारिक रूप से तय करना है. यह टेस्ट रनर और बिल्ड सिस्टम पर भी लागू होगा.
टेस्ट एनवायरमेंट के स्पेसिफ़िकेशन से, टेस्ट लिखने वालों को ऐसे व्यवहार पर भरोसा करने से बचने में मदद मिलती है जिसके बारे में बताया नहीं गया है. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने से जुड़े बदलाव करने की ज़्यादा स्वतंत्रता मिलती है. इस स्पेसिफ़िकेशन में, कुछ ऐसी कमियों को दूर किया गया है जिनकी वजह से, फ़िलहाल कई टेस्ट पास हो जाते हैं. हालांकि, वे पूरी तरह से हर्मेटिक, डिटरमिनिस्टिक, और रीएंट्रेंट नहीं होते.
इस पेज का मकसद, नियमों के मुताबिक जानकारी देना और भरोसेमंद स्रोत से जानकारी देना है. अगर इस स्पेसिफ़िकेशन और टेस्ट रनर के लागू किए गए व्यवहार में अंतर है, तो स्पेसिफ़िकेशन को प्राथमिकता दी जाएगी.
प्रस्तावित स्पेसिफ़िकेशन
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" जैसे मुख्य शब्दों का मतलब, IETF RFC 2119 में दिए गए मतलब के हिसाब से होना चाहिए.
टेस्ट का मकसद
Bazel टेस्ट का मकसद, रिपॉज़िटरी में चेक की गई सोर्स फ़ाइलों की किसी प्रॉपर्टी की पुष्टि करना है. (इस पेज पर, "सोर्स फ़ाइलों" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी गई कोई भी अन्य चीज़ शामिल है.) एक उपयोगकर्ता, एक ऐसा टेस्ट लिखता है जिससे यह पुष्टि की जा सके कि इनवेरिएंट को बनाए रखा गया है. अन्य उपयोगकर्ता, बाद में टेस्ट को एक्ज़ीक्यूट करते हैं. इससे यह पता चलता है कि इनवेरिएंट का उल्लंघन हुआ है या नहीं. अगर टेस्ट, सोर्स फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी अन्य वैरिएबल पर निर्भर करता है, तो इसकी वैल्यू कम हो जाती है. ऐसा इसलिए होता है, क्योंकि बाद के उपयोगकर्ताओं को यह पक्का नहीं होता कि टेस्ट पास न होने पर, उनके बदलावों में कोई गड़बड़ी है.
इसलिए, टेस्ट का नतीजा सिर्फ़ इन बातों पर निर्भर होना चाहिए:
- सोर्स फ़ाइलें जिन पर टेस्ट निर्भर करता है
- बिल्ड सिस्टम के वे प्रॉडक्ट जिन पर टेस्ट की निर्भरता है
- ऐसे संसाधन जिनके व्यवहार में, टेस्ट रनर के हिसाब से कोई बदलाव नहीं होता
फ़िलहाल, इस तरह के व्यवहार को रोकने के लिए कोई कार्रवाई नहीं की जाती. हालांकि, टेस्ट रनर के पास यह अधिकार होता है कि वे आने वाले समय में इस तरह के नियम लागू करें.
बिल्ड सिस्टम की भूमिका
टेस्ट के नियम, बाइनरी नियमों की तरह होते हैं. इनमें से हर नियम से, एक्ज़ीक्यूटेबल प्रोग्राम जनरेट होना चाहिए. कुछ भाषाओं के लिए, यह स्टब प्रोग्राम होता है. इसमें भाषा के हिसाब से हार्नेस को टेस्ट कोड के साथ जोड़ा जाता है. जांच के नियमों से अन्य आउटपुट भी जनरेट होने चाहिए. टेस्ट रनर को टेस्ट के मुख्य एक्ज़ीक्यूटेबल के अलावा, 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/. के फ़ाइल सिस्टम टाइप की जानकारी नहीं दी गई है.
टेस्ट, बिना बताए गए आउटपुट फ़ाइलों को एनोटेट करने के लिए, $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR में .part फ़ाइलें भी लिख सकते हैं.
कुछ मामलों में, टेस्ट को /tmp में फ़ाइलें बनाने के लिए मजबूर किया जा सकता है. उदाहरण के लिए, Unix डोमेन सॉकेट के लिए पाथ की लंबाई की सीमाएं आम तौर पर, सॉकेट को /tmp के तहत बनाने की ज़रूरत होती है. Bazel ऐसी फ़ाइलों को ट्रैक नहीं कर पाएगा. टेस्ट को खुद यह ध्यान रखना होगा कि वह हर्मेटिक हो. साथ ही, उसे यूनीक पाथ का इस्तेमाल करना होगा, ताकि एक साथ चल रहे अन्य टेस्ट और नॉन-टेस्ट प्रोसेस से टकराव न हो. इसके अलावा, उसे /tmp में बनाई गई फ़ाइलों को मिटाना होगा.
कुछ लोकप्रिय टेस्टिंग फ़्रेमवर्क, जैसे कि JUnit4 TemporaryFolder या Go TempDir, /tmp के तहत अस्थायी डायरेक्ट्री बनाने के अपने तरीके होते हैं. इन टेस्टिंग फ़्रेमवर्क में, /tmp में मौजूद फ़ाइलों को हटाने की सुविधा शामिल होती है. इसलिए, इनका इस्तेमाल किया जा सकता है. भले ही, ये /tmp से बाहर की फ़ाइलें बनाते हों.TEST_TMPDIR
टेस्ट को runfiles मैकेनिज़्म या एक्ज़ीक्यूशन एनवायरमेंट के अन्य हिस्सों के ज़रिए इनपुट ऐक्सेस करने चाहिए. ये हिस्से, इनपुट फ़ाइलों को उपलब्ध कराने के लिए खास तौर पर बनाए गए हैं.
टेस्ट को, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं करना चाहिए. ये आउटपुट, उनके खुद के एक्ज़ीक्यूटेबल की जगह से अनुमानित पाथ पर होते हैं.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिंबॉलिक लिंक या दोनों शामिल हैं. रनफ़ाइल ट्री में, डायरेक्ट्री के लिए सिमलंक शामिल हो सकते हैं.
जांच में, रनफ़ाइल ट्री में मौजूद .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए.
runfiles ट्री में मौजूद किसी भी डायरेक्ट्री, फ़ाइल या सिंबल लिंक (उन पाथ के साथ-साथ जो सिंबल लिंक को ट्रैवर्स करते हैं) को लिखा नहीं जाना चाहिए. (इसका मतलब है कि शुरुआती वर्किंग डायरेक्ट्री में बदलाव नहीं किया जा सकता.) जांचों में यह नहीं माना जाना चाहिए कि रनफ़ाइल का कोई भी हिस्सा लिखा जा सकता है या मौजूदा उपयोगकर्ता के पास उसका मालिकाना हक है. उदाहरण के लिए, chmod और chgrp फ़ेल हो सकते हैं.
टेस्ट के दौरान, रनफ़ाइल ट्री (इसमें सिमलंक से गुज़रने वाले पाथ भी शामिल हैं) में कोई बदलाव नहीं होना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में ऐसा कोई बदलाव नहीं होना चाहिए जिससे रनफ़ाइल ट्री में पाथ को हल करने के नतीजे पर असर पड़े.
जल्द बंद होने की समस्या का पता लगाने के लिए, टेस्ट शुरू होने पर TEST_PREMATURE_EXIT_FILE में बताई गई जगह पर एक फ़ाइल बना सकता है. इसके बाद, बंद होने पर उसे हटा सकता है. अगर Bazel को टेस्ट पूरा होने पर फ़ाइल दिखती है, तो वह यह मान लेगा कि टेस्ट समय से पहले बंद हो गया है. साथ ही, वह इसे फ़ेल के तौर पर मार्क कर देगा.
टैग के लिए तय किए गए नियम
जांच के नियमों में मौजूद कुछ टैग का खास मतलब होता है. Bazel Build Encyclopedia में tags एट्रिब्यूट के बारे में भी पढ़ें.
| टैग | मतलब |
|---|---|
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 को, runfiles डायरेक्ट्री में एक सिंबल लिंक के तौर पर दिखाया जाता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_nameहै. उदाहरण के लिए, सर्वर के लिए सिंबल लिंक का नाम$(WORKSPACE)/deps/server/serverहोगा और पूरा पाथ$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverहोगा. सिमलिंक का डेस्टिनेशन, OutputFile या CommandRule का OutputFileName() होता है. इसे ऐब्सलूट पाथ के तौर पर दिखाया जाता है. इसलिए, सिंबॉलिक लिंक का डेस्टिनेशन$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकता है. - सब-रनफ़ाइलों के लिए सिमलंक: हर
*_binary()Z के लिए, जो*_binary()C की रन-टाइम डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में Z की रनफ़ाइलों का दूसरा लिंक होता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिमलिंक का टारगेट, रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सबप्रोग्राम एक ही रनफ़ाइल डायरेक्ट्री शेयर करते हैं.