टेस्ट एक्ज़ीक्यूशन एनवायरमेंट की पूरी जानकारी.
बैकग्राउंड
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 |
कुल
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 |
असीमित या 2044KB <= rlim <= 8192KB |
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 मैकेनिज़्म या एक्ज़ीक्यूशन एनवायरमेंट के अन्य हिस्सों के ज़रिए इनपुट ऐक्सेस करने चाहिए. इन हिस्सों को खास तौर पर इनपुट फ़ाइलें उपलब्ध कराने के लिए बनाया गया है.
टेस्ट को, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं करना चाहिए. ये आउटपुट, उनके खुद के एक्ज़ीक्यूटेबल की जगह से अनुमानित पाथ पर होते हैं.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिंबॉलिक लिंक या दोनों शामिल हैं. रनफ़ाइल ट्री में, डायरेक्ट्री के लिए सिमलंक शामिल हो सकते हैं.
टेस्ट में, रनफ़ाइल ट्री में मौजूद .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए.
रनफ़ाइल ट्री में मौजूद किसी भी डायरेक्ट्री, फ़ाइल या सिमलंक (सिंबल लिंक) को बदला नहीं जा सकता. इसमें ऐसे पाथ भी शामिल हैं जो सिमलंक को ट्रैवर्स करते हैं. (इसका मतलब है कि शुरुआती वर्किंग डायरेक्ट्री में लिखने की अनुमति नहीं होनी चाहिए.) जांचों में यह नहीं माना जाना चाहिए कि रनफ़ाइल का कोई भी हिस्सा लिखा जा सकता है या मौजूदा उपयोगकर्ता के पास उसका मालिकाना हक है. उदाहरण के लिए, 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 को रनfiles डायरेक्ट्री में एक सिंबल लिंक से दिखाया जाता है. सिंबलिक लिंक का नाम$(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हो सकता है. - सब-रनफ़ाइलों के लिए सिमलंक: हर
*_binary()Z के लिए, जो*_binary()C की रन-टाइम डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में Z की रनफ़ाइलों का दूसरा लिंक होता है. सिंबलिक लिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिमलिंक का टारगेट, रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सबप्रोग्राम एक ही runfiles डायरेक्ट्री शेयर करते हैं.