टेस्ट करने के एनवायरमेंट की पूरी जानकारी.
बैकग्राउंड
Bazel BUILD भाषा में ऐसे नियम शामिल हैं जिनका उपयोग कई भाषाओं में स्वचालित टेस्ट प्रोग्राम को परिभाषित करने के लिए किया जा सकता है.
टेस्ट bazel test का इस्तेमाल करके किए जाते हैं.
उपयोगकर्ता सीधे टेस्ट बाइनरी भी इस्तेमाल कर सकते हैं. इसकी अनुमति है, लेकिन प्रमोशन नहीं किया जाता है, क्योंकि शुरू करने का तरीका, नीचे बताए गए मैंडेट का पालन नहीं करेगा.
टेस्ट बिना किसी क्रम के होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ वे रिसॉर्स ऐक्सेस करने चाहिए जिन पर उनका डिपेंडेंसी निर्भर होता है. अगर जांच के तरीके ठीक से नहीं हैं, तो वे लंबे समय तक चलने वाले नतीजे नहीं देते. यह गड़बड़ी खोजने (यह तय करने के लिए जो बदलाव टेस्ट को नुकसान पहुंचा रहा है), रिलीज़ इंजीनियरिंग ऑडिटेबिलिटी और टेस्ट आइसोलेशन (अपने-आप होने वाले टेस्टिंग फ़्रेमवर्क) को डीडीओएस सर्वर नहीं चाहिए, क्योंकि कुछ जांच इसकी वजह से होती है; यह एक गंभीर समस्या हो सकती है.
मकसद
इस पेज का मकसद है आधिकारिक तौर पर बेज़ल टेस्ट के लिए रनटाइम एनवायरमेंट सेट करना और लोगों की उम्मीद के मुताबिक काम करना. यह टेस्ट रनर और बिल्ड सिस्टम पर भी ज़रूरी शर्तें लागू करेगा.
टेस्ट एनवायरमेंट की खास जानकारी की मदद से, टेस्ट के लेखकों को उनके काम करने के तरीके पर भरोसा करने से बचा जा सकता है. इस तरह, टेस्ट इंफ़्रास्ट्रक्चर को लागू करने के तरीके में बदलाव करने की पूरी आज़ादी मिलती है. इस स्पेसिफ़िकेशन में कुछ कमियां हैं, जो समय-समय पर, खोज और जानकारी को सही तरीके से फ़िल्टर न करने के बावजूद, कई टेस्ट पास करने की अनुमति देती हैं.
इस पेज का मकसद भरोसेमंद और आधिकारिक, दोनों होना है. अगर स्पेसिफ़िकेशन की यह प्रक्रिया और टेस्ट रनर का लागू किया गया तरीका असहमत है, तो इस खासियत को प्राथमिकता दी जाती है.
प्रस्तावित विवरण
आईईटीएफ़ RFC 2119 के अनुसार, "मुख्य", "ज़रूरी", "ज़रूरी", "ज़रूरी", "शामिल नहीं", "होना चाहिए", "होना चाहिए", "सुझाया गया", "माया" और "ज़रूरी नहीं" होना चाहिए.
जांच करने का मकसद
Bazel की जांच का मकसद, सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है, जो रिपॉज़िटरी में सही का निशान लगाकर चुनी गई है. (इस पेज पर, "स्रोत फ़ाइलें" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल के तहत आने वाली बाकी चीज़ें शामिल हैं.) एक उपयोगकर्ता एक इन्वैरिएंट पर दावा करने के लिए एक टेस्ट लिखता है, जिसे वे बरकरार रखने की उम्मीद करते हैं. दूसरे उपयोगकर्ता बाद में टेस्ट करते हैं, ताकि यह पता चल सके कि इन्फ़ॉर्मैट का इस्तेमाल तो नहीं किया गया. (अगर टेस्ट, सोर्स फ़ाइल (बिना हेरमेटिक) के अलावा किसी भी वैरिएबल पर निर्भर होता है, तो इसकी वैल्यू कम हो जाती है. ऐसा इसलिए, क्योंकि बाद में उपयोगकर्ताओं को यह पक्का नहीं हो सकता कि टेस्ट में पास होने से पहले उनके बदलाव गलती से हो गए.
इसलिए, जांच का नतीजा सिर्फ़ इस पर निर्भर करता है:
- ऐसी सोर्स फ़ाइलें जिन पर टेस्ट के लिए एक डिपेंडेंसी इस्तेमाल की जाती है
- बिल्ड सिस्टम के वे प्रॉडक्ट जिनके लिए टेस्ट के बारे में साफ़ तौर पर बताया गया है
- ऐसे रिसॉर्स जिनके व्यवहार की जांच, टेस्ट रनर के स्थायी होने की गारंटी होती है
फ़िलहाल, ऐसा व्यवहार लागू नहीं किया गया है. हालांकि, जांच करने वाले लोगों के पास आने वाले समय में, इस तरह के नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को जोड़ने का अधिकार होता है.
बिल्ड सिस्टम की भूमिका
टेस्ट के नियम, बाइनरी नियमों से मिलते-जुलते हैं, जिनमें हर एक को एक्ज़ीक्यूटेबल प्रोग्राम होना चाहिए. कुछ भाषाओं के लिए, यह स्टब प्रोग्राम है, जिसमें खास तौर पर भाषा से जुड़े नियमों का इस्तेमाल किया जाता है. टेस्ट नियमों को दूसरे आउटपुट भी बनाने चाहिए. प्राथमिक जांच के एक्ज़ीक्यूटेबल के अलावा, टेस्ट रनर को runfiles के मेनिफ़ेस्ट की ज़रूरत होगी. यह ज़रूरी है कि रनटाइम के दौरान इनपुट वाली फ़ाइलें उपलब्ध कराई जाएं और उन्हें टेस्ट के टाइप, साइज़, और टैग की जानकारी मिले.
बिल्ड सिस्टम, कोड के साथ-साथ डेटा डिलीवर करने के लिए रनफ़ाइल का इस्तेमाल कर सकता है. (इसका इस्तेमाल हर जांच की बाइनरी को छोटा करने के लिए, ऑप्टिमाइज़ेशन के तौर पर किया जा सकता है. इसके लिए, जांच के दौरान फ़ाइलें शेयर करनी होंगी, जैसे कि डाइनैमिक लिंकिंग का इस्तेमाल करना.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई फ़ाइल एक्ज़ीक्यूट करने पर उपलब्ध टेस्ट फ़ाइल से मिली रनफ़ाइल इमेज के ज़रिए, इन फ़ाइलों को लोड करे. इसके बजाय, मूल या आउटपुट ट्री में मौजूद जगह की सटीक जानकारी को हार्डकोड करें.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक ऐसा प्रोग्राम है जिसे
execve() के साथ जोड़ा जा सकता है. जांच करने के दूसरे तरीके भी हो सकते हैं. उदाहरण के लिए, हो सकता है कि किसी आईडीई की वजह से Java की जांच के दौरान भी प्रोसेस चल सके. हालांकि, स्टैंडअलोन प्रोसेस के तौर पर टेस्ट चलाने के बाद, आधिकारिक नतीजा माना जाता है. टेस्ट
की प्रक्रिया पूरी होने पर, वह आम तौर पर शून्य और एग्ज़िट कोड के साथ खत्म हो जाती है. किसी भी अन्य नतीजे की जांच को असफल माना जाता है. खास तौर पर, PASS.FAIL या stdout में कोई भी स्ट्रिंग लिखने से,
टेस्ट रनर पर कोई असर नहीं पड़ता है.
अगर टेस्ट करने में ज़्यादा समय लगता है, तो कुछ संसाधनों की सीमा पार हो जाती है या टेस्ट करने वाले को प्रतिबंधित व्यवहार का पता चलता है, तो वह टेस्ट को मार सकता है और रनिंग को असफल मान सकता है. रनर को, टेस्ट की प्रक्रिया या उसके किसी सिग्नल को सिग्नल भेजने के बाद, टेस्ट पास होने की शिकायत नहीं करनी चाहिए.
पूरे टेस्ट टारगेट (अलग-अलग तरीकों या टेस्ट) को पूरा होने में तय समय दिया जाता है. टेस्ट के लिए समयसीमा,
timeout एट्रिब्यूट के हिसाब से दी गई है. यह इस टेबल पर आधारित है:
| टाइम आउट | समयसीमा (सेकंड में) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| शाश्वत | 3,600 |
टेस्ट के लिए, टाइम आउट की जानकारी साफ़ तौर पर नहीं दी गई होती है. इनमें, टेस्ट के 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 में बताई गई फ़ाइल की आखिरी बार बदलाव की तारीख बनानी या अपडेट करनी होगी. अगर
--incompatible_check_sharding_support
को चालू किया जाता है, तो बज़ेल के शार्ड होने पर, वह टेस्ट में फ़ेल हो जाएगा.
शुरुआती शर्तें
टेस्ट रन करते समय, टेस्ट करने वाले को कुछ शुरुआती शर्तें लागू करनी होंगी.
टेस्ट रनर को
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 |
एक राइटेबल डायरेक्ट्री में निजी फ़ाइल का पूरा पाथ. इस फ़ाइल का इस्तेमाल सिर्फ़ टेस्ट इन्फ़्रास्ट्रक्चर से होने वाली गड़बड़ियों की शिकायत करने के लिए किया जाना चाहिए. यह आम तौर पर जांच में होने वाली गड़बड़ी की शिकायत करने के सामान्य तरीके के तौर पर इस्तेमाल नहीं किया जाना चाहिए. इस मामले में, टेस्टिंग इंफ़्रास्ट्रक्चर को ऐसे सिस्टम या लाइब्रेरी के तौर पर बताया जाता है जो टेस्ट के हिसाब से नहीं होती हैं. हालांकि, इससे टेस्ट में खराबी आ सकती है. पहली लाइन में, उस टेस्ट इन्फ़्रास्ट्रक्चर के कॉम्पोनेंट का नाम दिया गया है जिसकी वजह से गड़बड़ी हुई. वहीं, दूसरी कॉम्पोनेंट में खराबी के बारे में पढ़ा जा सकने वाला ब्यौरा है. अतिरिक्त लाइनों को अनदेखा कर दिया जाता है.) | ज़रूरी नहीं |
TEST_LOGSPLITTER_OUTPUT_FILE |
a writable डायरेक्ट्री में मौजूद निजी फ़ाइल का पूरा पाथ (इसका इस्तेमाल, लॉगस्प्लिटर प्रोटोबफ़र लॉग लिखने के लिए किया जाता है) | ज़रूरी नहीं |
TEST_PREMATURE_EXIT_FILE |
a 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
डायरेक्ट्री में लिखी गई सभी फ़ाइलें zip हो जाएंगी और
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() की मदद से, फिर से पाया जा सके. शायद पूरक ग्रुप आईडी के लिए ये चीज़ें सही न हों.
मौजूदा उपयोगकर्ता के पास होम डायरेक्ट्री होनी चाहिए. हो सकता है कि यह लिखा न जा सके. टेस्ट को लिखने की कोशिश नहीं की जानी चाहिए.
नेटवर्किंग
होस्टनेम की जानकारी नहीं है. इसमें बिंदु हो सकता है या नहीं भी. होस्टनेम को हल करने के लिए, आपको मौजूदा होस्ट का आईपी पता देना होगा. पहले बिंदु के बाद होस्टनेम कट का समाधान करना भी कारगर होना चाहिए. होस्टनेम लोकल होस्ट को ठीक करना होगा.
अन्य संसाधन
जांच में सीपीयू का कम से कम एक कोर दिया जाता है. हो सकता है कि कुछ अन्य उपलब्ध हों, लेकिन इसकी गारंटी नहीं दी जाती है. इस कोर के अन्य प्रदर्शन पहलू तय नहीं किए गए हैं. आप जांच के नियम में "सीपीयू:एन" (जहां n एक पॉज़िटिव संख्या है) टैग जोड़कर, बुकिंग की संख्या को सीपीयू की संख्या में बढ़ा सकते हैं. हालांकि, जब किसी मशीन में सीपीयू की कुल क्षमता और अनुरोध किए गए कुल कोर कम होंगे, तब भी बैजल जांच करेगा. अगर कोई टेस्ट शार्डिंग का इस्तेमाल करता है, तो हर अलग-अलग शार्ड यहां बताए गए सीपीयू कोर की संख्या को रिज़र्व रखेगा.
टेस्ट से सबप्रोसेस बन सकते हैं, लेकिन ग्रुप या सेशन को प्रोसेस नहीं किया जा सकता.
टेस्ट में इस्तेमाल की जा सकने वाली इनपुट फ़ाइलों की संख्या तय होती है. इस सीमा में बदलाव हो सकता है. हालांकि, फ़िलहाल यह हज़ारों इनपुट में हो सकता है.
समय और तारीख
मौजूदा समय और तारीख नहीं बताई गई है. सिस्टम का समय क्षेत्र नहीं बताया गया है.
X Windows उपलब्ध हो भी सकता है और नहीं भी. X सर्वर की ज़रूरत वाली जांच को Xvfb शुरू करना चाहिए.
फ़ाइल सिस्टम के साथ इंटरैक्शन की जांच करना
जब तक कि कुछ अलग न बताया गया हो, तब टेस्ट एनवायरमेंट वैरिएबल में बताए गए सभी फ़ाइल पाथ, लोकल फ़ाइल सिस्टम में किसी जगह पर ले जाएंगे.
टेस्ट को सिर्फ़ $TEST_TMPDIR और $TEST_UNDECLARED_OUTPUTS_DIR (अगर सेट हो) में बताई गई डायरेक्ट्री में फ़ाइलें बनानी चाहिए.
ये डायरेक्ट्री शुरुआत में खाली रहेंगी.
टेस्ट को इन डायरेक्ट्री को हटाने, बदलने या उनमें बदलाव करने की कोशिश नहीं करनी चाहिए.
ये डायरेक्ट्री, सिंबॉलिक लिंक हो सकती हैं.
$TEST_TMPDIR/. के फ़ाइल सिस्टम के टाइप की जानकारी नहीं दी गई है.
टेस्ट, ऐसी आउटपुट फ़ाइलों की व्याख्या करने के लिए, $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR में .part फ़ाइलें भी लिख सकते हैं जिनके बारे में जानकारी नहीं दी गई है.
कुछ मामलों में, एक टेस्ट लागू करके, /tmp में फ़ाइलें बनाई जा सकती हैं. उदाहरण के लिए,
यूनिक्स डोमेन सॉकेट के लिए पाथ की लंबाई की सीमाएं
आम तौर पर, /tmp के तहत सॉकेट बनाना ज़रूरी है. Bazel, इन फ़ाइलों को ट्रैक नहीं कर पाएगा. हालांकि, जांच को सोच समझकर, यूनीक पाथ का इस्तेमाल करने, टेस्ट और नॉन-टेस्ट प्रोसेस चलाने, और /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() नियम, कंपाइल करने में लगने वाले समय पर निर्भर है या नहीं. रनटाइम फ़ाइलें डायरेक्ट्री, BUILD फ़ाइलों के सेट पर निर्भर करती हैं. इन फ़ाइलों का असर *_binary() नियम या कंपाइल टाइम या रनटाइम के हिसाब से लागू होने वाली फ़ाइलों पर पड़ता है. सोर्स फ़ाइलों में बदलाव करने से, रनटाइम फ़ाइलों की डायरेक्ट्री पर कोई असर नहीं पड़ता. इस वजह से, इमारत को फिर से बनाने के लिए ट्रिगर नहीं होता.
विषय सूची
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल होती हैं:
- रन-टाइम डिपेंडेंसी के सिमलिंक: हर EnergyFile और CommandRule,
जो
*_binary()नियम की रन-टाइम डिपेंडेंसी है, उसे रनफ़ाइल डायरेक्ट्री में एक सिमलिंक से दिखाया जाता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_nameहै. उदाहरण के लिए, सर्वर के लिए सिमलिंक का नाम$(WORKSPACE)/deps/server/serverहोगा, और पूरा पाथ$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverहोगा. सिमलिंक का डेस्टिनेशन, EnergyFile या CommandRule का EnergyFileName(), एक ऐब्सलूट पाथ के रूप में दिखाया जाता है. इस तरह, लिंक का डेस्टिनेशन$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकता है. - सब-रनफ़ाइल को सिमलिंक करना: हर
*_binary()Z के लिए, जो*_binary()C की रनिंग डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में दूसरा लिंक Z का होता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिमलिंक का टारगेट, रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सब-प्रोग्राम एक जैसी रनरन वाली डायरेक्ट्री शेयर करते हैं.