टेस्ट एक्ज़ीक्यूशन के बारे में पूरी जानकारी.
बैकग्राउंड
Bazel BUILD भाषा में ऐसे नियम शामिल हैं जिनका इस्तेमाल कई भाषाओं में अपने-आप होने वाले टेस्ट प्रोग्राम तय करने के लिए किया जा सकता है.
टेस्ट bazel test का इस्तेमाल करके चलाए जाते हैं.
उपयोगकर्ता सीधे टेस्ट बाइनरी भी चला सकते हैं. इसकी अनुमति है, लेकिन प्रचार नहीं किया जाता, क्योंकि ऐसा शुरू करने के लिए, नीचे दिए गए मैंडेट का पालन नहीं करना होगा.
टेस्ट बिना किसी बदलाव के होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ उन रिसॉर्स को ऐक्सेस करना चाहिए जिन पर उनका एलान किया गया है. अगर जांच के नतीजे सही तरीके से नहीं दिए जाते हैं, तो पुराने हो जाने वाले नतीजे नहीं मिलते. यह अपराधी को ढूंढने में एक बड़ी समस्या हो सकती है (यह पता लगाने के लिए कि कौनसा बदलाव टेस्ट करने लायक है), इंजीनियरिंग ऑडिटेबिलिटी, और टेस्ट आइसोलेशन के टेस्ट (अपने-आप होने वाले टेस्टिंग फ़्रेमवर्क, DDOS के लिए ज़रूरी नहीं हैं, क्योंकि कुछ टेस्ट से बात करते हैं).
उद्देश्य
इस पेज का मकसद औपचारिक तौर पर Bazel टेस्ट के लिए रनटाइम एनवायरमेंट और तैयार करना है. साथ ही, इससे टेस्ट रनर और बिल्ड सिस्टम पर ज़रूरी शर्तें लागू हो जाएंगी.
टेस्ट एनवायरमेंट की खास बातों की मदद से, टेस्ट लेखकों को बिना बताए किए गए व्यवहार पर भरोसा करने से बचना चाहिए. इसलिए, उन्हें लागू करने के तरीके में बदलाव करने की आज़ादी मिल जाती है. इस स्पेसिफ़िकेशन की वजह से कुछ होल हो जाते हैं, जो मौजूदा समय में कई जांचों को पूरा करने में मदद करते हैं. भले ही, वे सही तरीके से काम न करते हों, किसी समस्या की पहचान करते हों, और एक ही प्रॉडक्ट को बार-बार दिखाने की अनुमति न हो.
इस पेज का मकसद, भरोसेमंद और भरोसेमंद, दोनों तरह का कॉन्टेंट दिखाना है. अगर इस तरह की खासियत और इसे लागू करने वाले लोगों में इस तरह का व्यवहार लागू नहीं होता है, तो इनके बारे में प्राथमिकता दी जाती है.
प्रस्तावित विवरण
"ज़रूरी है", "ज़रूरी नहीं", "ज़रूरी", "खरीदें", "नहीं", "या नहीं", "नहीं", "सुझाया गया", "मई", और "ज़रूरी नहीं" को आईईटीएफ़ आरएफ़सी 2119 में बताया गया है.
जांच का मकसद
Bazel की जांच का मकसद, स्रोत फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है जो डेटा स्टोर करने की जगह पर जांच की गई है. (इस पेज पर, "स्रोत फ़ाइलें" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल वाली सभी चीज़ें शामिल हैं.) एक उपयोगकर्ता ऐसे वैरिएंट पर दावा करने के लिए एक टेस्ट लिखता है जिसे वह बनाए रखने की उम्मीद करता है. अन्य उपयोगकर्ता जांच के लिए बाद में जांच करते हैं, ताकि यह जान सकें कि वैरिएंट में कोई गड़बड़ी हुई है या नहीं. अगर जांच के लिए, सोर्स फ़ाइलों के अलावा किसी दूसरे वैरिएबल का इस्तेमाल किया जाता है (ऐसा उन फ़ाइलों के लिए नहीं किया जाता जो किसी काम की नहीं हैं), तो उसकी वैल्यू कम हो जाती है. ऐसा इसलिए होता है, क्योंकि जांच के दौरान पास होने से पहले उपयोगकर्ताओं को पक्के तौर पर पता नहीं चल पाता कि उनके बदलाव सही नहीं हैं.
इसलिए, जांच का नतीजा सिर्फ़ इस बात पर निर्भर करना चाहिए:
- वे सोर्स फ़ाइलें जिन पर टेस्ट के लिए, डिपेंडेंसी इस्तेमाल की गई है
- बिल्ड सिस्टम के वे प्रॉडक्ट जिन पर टेस्ट के लिए, एक डिपेंडेंसी लागू होती है
- ऐसे संसाधन जिनके व्यवहार की गारंटी टेस्ट रनर से स्थायी रहने के लिए दी जाती है
फ़िलहाल, ऐसा नहीं किया जा सकता. हालांकि, रनर गेम में आने वाले समय में, इस तरह के नियम लागू करने का अधिकार है.
बिल्ड सिस्टम से जुड़ी भूमिका
जांच के नियम, बाइनरी नियमों के समान होते हैं. हर नियम के लिए एक्ज़ीक्यूटेबल प्रोग्राम ज़रूरी है. कुछ भाषाओं के लिए, यह एक स्टब प्रोग्राम होता है. इसमें खास भाषा और भाषा का इस्तेमाल करने वाले टेस्ट कोड को, कोड के साथ जोड़ा जाता है. टेस्ट के नियमों को दूसरे आउटपुट भी बनाने होंगे. प्राथमिक जांच के एक्ज़ीक्यूटेबल के अलावा, टेस्ट रनर को runfiles के मेनिफ़ेस्ट की ज़रूरत होगी. यह ज़रूरी है कि इनपुट फ़ाइलें रनटाइम के दौरान उपलब्ध कराई जाएं. साथ ही, इसमें टेस्ट के टाइप, साइज़, और टैग के बारे में जानकारी भी देनी पड़ सकती है.
बिल्ड सिस्टम, कोड और साथ ही डेटा डिलीवर करने के लिए, रनफ़ाइल का इस्तेमाल कर सकता है. (इस सेटिंग का इस्तेमाल, ऑप्टिमाइज़ेशन के तौर पर किया जा सकता है. इससे, जांच के दौरान फ़ाइलें शेयर करके, हर टेस्ट बाइनरी को छोटा किया जा सकता है. जैसे, डाइनैमिक लिंकिंग का इस्तेमाल करके. बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट किया गया एक्ज़ीक्यूटेबल, इन फ़ाइलों को रनर इमेज के ज़रिए लोड करे. इसके लिए, उन्हें सोर्स या आउटपुट ट्री में पूरी तरह से रैंक वाली हार्डकोड वाली फ़ाइलों के बारे में न बताएं.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक ऐसा प्रोग्राम होता है जिसे execve() के साथ शुरू किया जा सकता है. जांच करने के दूसरे तरीके भी हो सकते हैं. उदाहरण के लिए, हो सकता है कि एक IDE प्रोसेस के दौरान Java की जांच को एक्ज़ीक्यूट करने की अनुमति दे. हालांकि, स्टैंडअलोन प्रक्रिया के तौर पर जांच चलाने के नतीजे को भरोसेमंद माना जाना चाहिए. अगर कोई जांच की प्रक्रिया पूरी होती है और खत्म होने का समय शून्य होता है, तो टेस्ट पास हो जाता है. अन्य किसी भी नतीजे को जांच में सफल नहीं माना जाता है. खास तौर पर, stdout में PASS या FAIL किसी भी स्ट्रिंग को लिखने से,
टेस्ट रनर का कोई फ़ायदा नहीं होता.
अगर जांच करने में बहुत ज़्यादा समय लगता है, जांच में तय सीमा से ज़्यादा संसाधन आते हैं या टेस्ट करने वाला व्यक्ति किसी ऐसे व्यवहार का पता लगाता है जिस पर पाबंदी लगी है, तो वह जांच को नाकाम कर सकता है. साथ ही, जांच को असफल मान सकता है. रनर को, टेस्ट की प्रोसेस या उसके किसी बच्चे के बारे में सिग्नल भेजने के बाद, टेस्ट को पास होने की शिकायत नहीं करनी चाहिए.
पूरे टेस्ट टारगेट को (अलग-अलग तरीकों या टेस्ट को नहीं) पूरा करने के लिए सीमित समय दिया जाता है. टेस्ट के लिए समयसीमा, नीचे दी गई टेबल के हिसाब से उसकी timeout एट्रिब्यूट पर आधारित होती है:
| टाइम आउट | समयसीमा (सेकंड में) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| इटर्नल | 3600 |
टाइम आउट की जानकारी साफ़ तौर पर नहीं देने वाली जांचों में size शामिल है. यह जांच इस तरह की जाती है:
| साइज़ | शामिल समय खत्म होने का लेबल |
|---|---|
| छोटा | छोटा |
| मीडियम | मध्यम |
| बड़ा | लंबा |
| विशाल | इटर्नल |
बिना "साफ़ तौर पर टाइम आउट" सेटिंग वाले "बड़ी" जांच के लिए, 900 सेकंड दिए जाएंगे. "छोटा" समय खत्म होने के बाद "मीडियम" टेस्ट के लिए, 60 सेकंड का समय दिया जाएगा.
timeout के उलट, size टेस्ट को स्थानीय रूप से चलाते समय, दूसरे संसाधनों (जैसे कि रैम) के इस्तेमाल का आकलन करता है, जैसा कि सामान्य परिभाषाओं में बताया गया है.
size और timeout लेबल के सभी कॉम्बिनेशन कानूनी हैं. इसलिए, हो सकता है कि "बहुत बड़े" टेस्ट का समय खत्म होने का समय "शॉर्ट" हो. लगता है कि यह कुछ बहुत ही भयानक चीज़ों को बहुत जल्दी कर देता है.
टाइम आउट पर ध्यान दिए बिना, टेस्ट कभी भी बिना किसी क्रम के लौटाए जा सकते हैं. टेस्ट में बहुत ज़्यादा समय लगने पर जुर्माना नहीं लगाया जाता है, हालांकि चेतावनी जारी की जा सकती है: आपको आम तौर पर, टाइम आउट को जितना हो सके उतना सटीक तरीके से सेट करना चाहिए.
टेस्ट टाइम आउट, --test_timeout बेज़ल फ़्लैग के साथ बदला जा सकता है. ऐसा तब होता है, जब यह मैन्युअल रूप से ऐसी स्थितियों में चलता है जो धीमे काम करते हैं. --test_timeout की वैल्यू सेकंड में दी गई है. उदाहरण के लिए, --test_timeout=120
टेस्ट टाइम आउट को दो मिनट के लिए सेट करता है.
जांच समय खत्म होने की सीमा के लिए यहां सुझाव भी दिया गया है:
| टाइम आउट | कम से कम समय (सेकंड) |
|---|---|
| छोटा | 0 |
| मध्यम | 30 |
| लंबा | 300 |
| इटर्नल | 900 |
उदाहरण के लिए, अगर "मॉडरेट" टेस्ट 5.5 सेकंड में पूरा होता है, तो timeout =
"short" या size = "small" सेट करें. बेज़ल --test_verbose_timeout_warnings
कमांड लाइन विकल्प का इस्तेमाल करने से, उन टेस्ट को दिखाया जाएगा जिनका साइज़ बड़ा है.
खास जानकारी के मुताबिक, BUILD फ़ाइल में टेस्ट के साइज़ और टाइम आउट की जानकारी यहां दी जाती है. अगर इसे तय न किया गया हो, तो टेस्ट का साइज़ डिफ़ॉल्ट रूप से "मीडियम" पर सेट होगा.
अगर टेस्ट एग्ज़िट की मुख्य प्रोसेस है, लेकिन उसके कुछ बच्चे अब भी चल रहे हैं, तो टेस्ट रनर को दौड़ को पूरा करना चाहिए और इसे मुख्य प्रोसेस से मिले एग्ज़िट कोड के आधार पर सफलता या फ़ेल के रूप में गिना जाना चाहिए. टेस्ट रनर किसी भी तरीके से किया जा सकता है. जांच के ज़रिए इस तरीके से लीक नहीं होना चाहिए.
शार्डिंग की जांच करें
टेस्ट शार्डिंग के ज़रिए टेस्ट को शेयर किया जा सकता है. टेस्ट शार्डिंग चालू करने के लिए, --test_sharding_strategy और shard_count देखें. शार्डिंग चालू होने पर, हर रनर के लिए एक बार टेस्ट रनर लॉन्च किया जाता है. एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS, शार्ड की संख्या है और TEST_SHARD_INDEX शार्ड इंडेक्स है, जो 0 से शुरू होता है. दौड़ने वाले इस जानकारी का इस्तेमाल करके, यह जांच करते हैं कि किस तरह की जांच करनी है - उदाहरण के लिए, राउंड-रॉबिन रणनीति का इस्तेमाल करके. परीक्षा देने वाले सभी लोगों के पास
शार्डिंग की सुविधा नहीं होती. अगर रनिंग से शार्डिंग की सुविधा काम करती है, तो उसे
TEST_SHARD_STATUS_FILE में बताई गई फ़ाइल की पिछली बार बदली गई तारीख को बनाना या अपडेट करना होगा. इसके अलावा, Bazel को लगता है कि यह शार्डिंग के साथ काम नहीं करता. इसके अलावा, यह दूसरे धावक भी लॉन्च नहीं करेगा.
शुरुआती शर्तें
टेस्ट करते समय, टेस्ट रनर को कुछ शुरुआती शर्तें तय करनी होंगी.
टेस्ट रनर को, हर जांच को argv[0] में टेस्ट एक्ज़ीक्यूटेबल के पाथ के साथ शुरू करना चाहिए. यह पाथ टेस्ट की मौजूदा डायरेक्ट्री से मिलता-जुलता होना चाहिए
(जो रन फ़ाइलें ट्री में होता है, नीचे देखें). जब तक उपयोगकर्ता साफ़ तौर पर अनुरोध न करे, तब तक टेस्ट रनर को कोई दूसरा आर्ग्युमेंट पास नहीं करना चाहिए.
शुरुआती एनवायरमेंट ब्लॉक इस तरह का होगा:
| वैरिएबल | वैल्यू | स्थिति |
|---|---|---|
HOME |
$TEST_TMPDIR की वैल्यू |
सुझाया गया |
LANG |
सेट नहीं है | इसे भरना ज़रूरी है |
LANGUAGE |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_ALL |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_COLLATE |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_CTYPE |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_MESSAGES |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_MONETARY |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_NUMERIC |
सेट नहीं है | इसे भरना ज़रूरी है |
LC_TIME |
सेट नहीं है | इसे भरना ज़रूरी है |
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 |
Writable डायरेक्ट्री में निजी फ़ाइल का पूरा पाथ (इस फ़ाइल का इस्तेमाल सिर्फ़ जांच से जुड़े इन्फ़्रास्ट्रक्चर से होने वाली गड़बड़ियों की रिपोर्ट करने के लिए किया जाना चाहिए, न कि जांच में असफल होने की आम प्रक्रिया के रूप में. इस संदर्भ में, टेस्टिंग इंफ़्रास्ट्रक्चर को सिस्टम या लाइब्रेरी के तौर पर बताया जाता है, जो टेस्ट के लिए खास नहीं होते, लेकिन उनमें खराबी की वजह से टेस्ट फ़ेल हो सकता है. पहली लाइन में, जांच में मदद करने वाले कॉम्पोनेंट का नाम होता है जिसकी वजह से गड़बड़ी होती है. वहीं, दूसरे कॉम्पोनेंट को फ़ेल होने की वजह माना जाता है. लाइन को अनदेखा किया जाता है.) | ज़रूरी नहीं |
TEST_LOGSPLITTER_OUTPUT_FILE |
Writable डायरेक्ट्री में मौजूद निजी फ़ाइल का पूरा पाथ | ज़रूरी नहीं |
TEST_PREMATURE_EXIT_FILE |
Writable डायरेक्ट्री में निजी फ़ाइल का पूरा पाथ (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,
अगर sharding का इस्तेमाल किया गया हो |
ज़रूरी नहीं |
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 |
वह जगह जहां टेस्ट कार्रवाइयों को जांच के नतीजे वाली एक्सएमएल आउटपुट फ़ाइल लिखनी चाहिए. नहीं तो, बैज़ेल टेस्ट लॉग के तौर पर टेस्ट लॉग को रैप करके, एक डिफ़ॉल्ट एक्सएमएल आउटपुट फ़ाइल जनरेट करता है. एक्सएमएल स्कीमा, JUnit टेस्ट के नतीजे से जुड़े स्कीमा पर आधारित होता है. | ज़रूरी नहीं |
BAZEL_TEST |
यह दिखाता है कि bazel test से जांच की जा रही है |
इसे भरना ज़रूरी है |
एनवायरमेंट में और एंट्री हो सकती हैं. टेस्ट, किसी भी एनवायरमेंट वैरिएबल के मौजूद होने, मौजूद न होने या उसकी वैल्यू पर निर्भर नहीं होने चाहिए.
काम करने की शुरुआती डायरेक्ट्री $TEST_SRCDIR/$TEST_WORKSPACE होगी.
मौजूदा प्रोसेस आईडी, प्रोसेस ग्रुप आईडी, सेशन आईडी, और पैरंट प्रोसेस आईडी की जानकारी नहीं दी गई है. यह प्रक्रिया, किसी समूह के लीडर या सेशन का लीडर हो सकती है या नहीं. प्रोसेस में कंट्रोल करने वाला टर्मिनल हो भी सकता है या नहीं भी. इस प्रोसेस में, शून्य या उससे ज़्यादा, बिना अनुमति के चलने वाली चाइल्ड प्रोसेस हो सकती हैं. जब टेस्ट कोड कंट्रोल कर लिया जाता है, तो इस प्रोसेस में कई थ्रेड नहीं होने चाहिए.
फ़ाइल डिस्क्रिप्टर 0 (stdin) पढ़ने के लिए खुला होगा, लेकिन यह नहीं बताया जाएगा कि यह क्या अटैच किया गया है. जांच को इसे नहीं पढ़ना चाहिए. फ़ाइल डिस्क्रिप्टर 1 (stdout) और 2
(stderr) लिखने के लिए खुले होने चाहिए, लेकिन यह उनके बारे में नहीं बताया गया है. यह एक टर्मिनल, पाइप, एक सामान्य फ़ाइल या कुछ और ऐसा हो सकता है
जो वर्ण लिखे जा सकते हैं. वे खुली हुई फ़ाइल की टेबल में कोई एंट्री शेयर कर सकते हैं
(इसका मतलब है कि वे अलग से अपना अनुरोध नहीं कर सकते). टेस्ट में किसी भी दूसरे ओपन फ़ाइल डिस्क्रिप्टर को शामिल नहीं किया जाना चाहिए.
शुरुआती उमस्क 022 या 027 होगा.
कोई अलार्म या अंतराल टाइमर लंबित नहीं होगा.
ब्लॉक किए गए सिग्नल के शुरुआती मास्क वाले फ़ील्ड को खाली छोड़ दिया जाएगा. सभी सिग्नल को डिफ़ॉल्ट कार्रवाई पर सेट किया जाएगा.
सॉफ़्ट और हार्ड, दोनों संसाधनों की शुरुआती सीमाएं इस तरह सेट की जानी चाहिए:
| रिसॉर्स | सीमा |
|---|---|
RLIMIT_AS |
अनलिमिटेड |
RLIMIT_CORE |
तय नहीं है |
RLIMIT_CPU |
अनलिमिटेड |
RLIMIT_DATA |
अनलिमिटेड |
RLIMIT_FSIZE |
अनलिमिटेड |
RLIMIT_LOCKS |
अनलिमिटेड |
RLIMIT_MEMLOCK |
अनलिमिटेड |
RLIMIT_MSGQUEUE |
तय नहीं है |
RLIMIT_NICE |
तय नहीं है |
RLIMIT_NOFILE |
कम से कम 1024 |
RLIMIT_NPROC |
तय नहीं है |
RLIMIT_RSS |
अनलिमिटेड |
RLIMIT_RTPRIO |
तय नहीं है |
RLIMIT_SIGPENDING |
तय नहीं है |
RLIMIT_STACK |
अनलिमिटेड या 2044केबी <= रीलिम <= 8192केबी |
शुरुआती प्रोसेस में लगने वाले समय (जैसा कि times() में दिखता है) और संसाधन के इस्तेमाल (जैसे कि getrusage() तक लौटाए गए) की जानकारी नहीं दी जाती है.
शेड्यूल करने की शुरुआती नीति और प्राथमिकता तय नहीं की गई है.
होस्ट सिस्टम की भूमिका
टेस्ट रनर के सीधे तौर पर कंट्रोल के तहत, उपयोगकर्ता संदर्भ के अलग-अलग पहलुओं के अलावा, जिस ऑपरेटिंग सिस्टम पर जांच की जाती है उसे मान्य जांच के लिए कुछ प्रॉपर्टी पूरी करनी होंगी.
फ़ाइल सिस्टम
किसी जांच में देखी गई रूट डायरेक्ट्री, रूट रूट डायरेक्ट्री हो सकती है या नहीं भी.
/proc को माउंट किया जाना चाहिए.
बिल्ड के सभी टूल /usr में तय किए गए ऐब्सलूट पाथ में मौजूद होंगे.
इनका इस्तेमाल लोकल इंस्टॉलेशन में किया जाता है.
हो सकता है कि /home से शुरू होने वाले पाथ उपलब्ध न हों. टेस्ट को ऐसे किसी पाथ
को ऐक्सेस नहीं करना चाहिए.
/tmp लिखा जा सकता है, लेकिन टेस्ट को इन पाथ का इस्तेमाल करने से बचना चाहिए.
जांच में यह नहीं माना जाना चाहिए कि कोई खास स्थायी पाथ उसके खास इस्तेमाल के लिए उपलब्ध है.
जांच में यह नहीं माना जाना चाहिए कि माउंट किए गए किसी भी फ़ाइल सिस्टम के लिए टाइमिंग चालू है.
उपयोगकर्ता और समूह
उपयोगकर्ता, रूट, कोई नहीं, और Unittest मौजूद होने चाहिए. समूह रूट करें, कोई भी नहीं, और सहभागिता मौजूद होना चाहिए.
जांच, गैर-रूट उपयोगकर्ता के तौर पर की जानी चाहिए. असली उपयोगकर्ता आईडी एक जैसे होने चाहिए; इसी तरह ग्रुप आईडी के लिए भी एक जैसे होने चाहिए. इसके अलावा, मौजूदा उपयोगकर्ता आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप का नाम तय नहीं किया जाता है. पूरक ग्रुप आईडी का सेट तय नहीं किया गया है.
मौजूदा उपयोगकर्ता आईडी और ग्रुप आईडी में मिलते-जुलते नाम होने चाहिए, जिन्हें getpwuid() और getgrgid() की मदद से फिर से लाया जा सके. ऐसा हो सकता है कि पूरक ग्रुप आईडी के लिए भी ऐसा न हो.
मौजूदा उपयोगकर्ता के पास होम डायरेक्ट्री होनी चाहिए. हो सकता है कि यह लिखा न जा सके. टेस्ट को इसे लिखने की कोशिश नहीं करनी चाहिए.
नेटवर्किंग
होस्टनाम नहीं बताया गया है. इसमें बिंदु हो भी सकता है या नहीं भी. होस्टनेम को ठीक करने से मौजूदा होस्ट का आईपी पता मिलना ज़रूरी है. पहले बिंदु के बाद होस्टनेम कट का समाधान करना भी ज़रूरी है. होस्टनेम लोकल होस्ट को ठीक करना होगा.
दूसरे संसाधन
जांच के लिए कम से कम एक सीपीयू कोर दिया जाता है. हो सकता है कि कुछ वर्शन उपलब्ध हों, लेकिन इसकी गारंटी नहीं है. इस कोर के अन्य प्रदर्शन पहलू तय नहीं किए गए हैं. आप जांच नियम के लिए "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 में सॉकेट बनाने की ज़रूरत होती है. बेज़ेल ऐसी फ़ाइलों को ट्रैक नहीं कर पाएंगे. उन्हें टेस्ट करने के लिए, हर तरीके से सावधानी बरतनी होगी. साथ ही, दूसरे पाथ से टकराने से बचने के लिए, टेस्ट और नॉन-टेस्ट प्रोसेस चलाने के साथ-साथ
/tmp में बनाई गई फ़ाइलों को साफ़ करना होगा.
टेस्टिंग के कुछ लोकप्रिय फ़्रेमवर्क, जैसे कि
JUnit4 TemporaryFolder
या Go TempDir, अपने-अपने तरीके से /tmp में अस्थायी डायरेक्ट्री बनाते हैं. जांच करने वाले इन फ़्रेमवर्क में, /tmp में मौजूद फ़ाइलों को हटाने वाले फ़ंक्शन शामिल होते हैं. इसलिए, आप इनका इस्तेमाल तब भी कर सकते हैं, जब वे TEST_TMPDIR से बाहर की फ़ाइलें बनाएं.
जांच में, रनफ़ाइल मैकेनिज़्म या एक्ज़ीक्यूशन एनवायरमेंट के दूसरे हिस्सों से इनपुट ऐक्सेस किए जाने चाहिए. इनका इस्तेमाल खास तौर पर इनपुट फ़ाइलें उपलब्ध कराने के लिए किया जाता है.
टेस्ट को अपने खुद के एक्ज़ीक्यूटेबल की जगह से अनुमानित पाथ पर बिल्ड सिस्टम के दूसरे आउटपुट ऐक्सेस नहीं करने चाहिए.
यह तय नहीं है कि रन फ़ाइलें ट्री में सामान्य फ़ाइलें, सिंबल लिंक, या मिक्स मिक्स शामिल हैं या नहीं. रनफ़ाइल ट्री में डायरेक्ट्री के लिए, सिमलिंक हो सकते हैं.
टेस्ट में उन पाथ का इस्तेमाल नहीं करना चाहिए जिनमें .. फ़ाइलें, रन फ़ाइलें ट्री में शामिल हों.
रन फ़ाइलें (इसमें वे पाथ भी शामिल हैं जो सिमलिंक होते हैं) में कोई भी डायरेक्ट्री, फ़ाइल या सिमलिंक नहीं होना चाहिए. (इसके बाद, शुरुआती वर्किंग डायरेक्ट्री को लिखा नहीं जा सकता.) जांच में यह नहीं माना जाना चाहिए कि रनून
का कोई हिस्सा लिखा जा सकने वाला है या मौजूदा उपयोगकर्ता के पास है (उदाहरण के लिए, chmod और chgrp
काम नहीं कर सकता).
टेस्ट करने के दौरान, रन रन ट्री (इसमें वे पाथ भी शामिल हैं जो सिम्बॉल को पार करते हैं) में बदलाव नहीं होना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट को किसी भी तरह से नहीं बदलना चाहिए, जो रनफ़ाइल ट्री के अंदर पाथ के समाधान के नतीजे पर असर डालता है.
रिलीज़ होने से पहले इस्तेमाल किए जाने से बचने के लिए, हो सकता है कि जांच शुरू होने पर TEST_PREMATURE_EXIT_FILE के बताए गए पाथ पर फ़ाइल बने. साथ ही, एग्ज़िट करने पर इसे हटाया जा सकता है. अगर बेज़ल को टेस्ट पूरा होने के बाद फ़ाइल दिखती है, तो यह माना जाएगा कि टेस्ट समय से पहले खत्म हो गया है और उसे 'पूरा नहीं हुआ' के तौर पर मार्क किया गया है.
टैग कन्वेंशन
जांच के नियमों में कुछ टैग का खास मतलब होता है. tags एट्रिब्यूट पर बेज़ल बिल्ड एनसाइक्लोपीडिया भी देखें.
| टैग | लिंक |
|---|---|
exclusive |
एक ही समय पर कोई दूसरी जांच न करें |
external |
टेस्ट में एक बाहरी डिपेंडेंसी है; टेस्ट कैशिंग बंद करें |
large |
test_suite कन्वेंशन; बड़े टेस्ट का सुइट |
manual * |
:..., :* या :all जैसे वाइल्डकार्ड टारगेट पैटर्न में टेस्ट टारगेट शामिल न करें |
medium |
test_suite कन्वेंशन; मीडियम टेस्ट का सुइट |
small |
test_suite कन्वेंशन; छोटे टेस्ट का सुइट |
smoke |
test_suite कन्वेंशन; इसका मतलब है कि इसे वर्शन कंट्रोल सिस्टम में, कोड में बदलाव करने से पहले चलाया जाना चाहिए |
रन फ़ाइलें
नीचे दिए गए नियम में, मान लें कि
//foo/bar:unittest लेबल वाला *_binary() नियम है, जिसमें रन-टाइम डिपेंडेंसी
//deps/server:server है.
जगह की जानकारी
टारगेट //foo/bar:unittest के लिए, रन फ़ाइलें डायरेक्ट्री डायरेक्ट्री है
$(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. इस पाथ को runfiles_dir कहा जाता है.
डिपेंडेंसी
रन फ़ाइलें डायरेक्ट्री को *_binary() नियम के कंपाइल समय के हिसाब से कंपाइल किया जाता है. रन फ़ाइलें डायरेक्ट्री, BLILD फ़ाइलों के सेट पर निर्भर करती है, जो *_binary() नियम या कंपाइल के समय या रन टाइम पर निर्भर करती है. सोर्स फ़ाइलों में बदलाव करने से, Runfiles की डायरेक्ट्री के स्ट्रक्चर पर कोई असर नहीं पड़ता. साथ ही, इस वजह से फ़ाइल को फिर से बनाने में कोई ट्रिगर नहीं होता.
कॉन्टेंट
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल हैं:
- रन-टाइम डिपेंडेंसी के सिमलाइन: हर IMPORTFile और CommandRule
, जो
*_binary()नियम की रन-टाइम डिपेंडेंसी है, रनफ़ाइल डायरेक्ट्री में एक सिमलिंक से दिखाई जाती है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_nameहै. उदाहरण के लिए, सर्वर का सिमलिंक,$(WORKSPACE)/deps/server/serverहोना चाहिए और पूरा पाथ$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverहोगा. सिमलिंक का डेस्टिनेशन, InputFile या CommandRule के InputFileName() को एक सटीक पाथ के तौर पर दिखाया जाता है. इसलिए, सिमलिंक की मंज़िल$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकती है. - सब-रनफ़ाइल के लिए सिमलाइन: हर
*_binary()Z के लिए जो*_binary()C का रनटाइम डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में दूसरा लिंक Z का रन फ़ाइलें है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिम्लिंक का टारगेट, रन फ़ाइलें डायरेक्ट्री है. उदाहरण के लिए, सभी सबप्रोग्राम एक सामान्य रन फ़ाइलें डायरेक्ट्री शेयर करते हैं.