टेस्ट प्रोग्राम चलाने के लिए एनवायरमेंट की पूरी जानकारी.
बैकग्राउंड
Bazel BUILD भाषा में ऐसे नियम शामिल हैं जिनका इस्तेमाल कई भाषाओं में, अपने-आप होने वाले टेस्ट प्रोग्राम को तय करने के लिए किया जा सकता है.
टेस्ट, bazel test का इस्तेमाल करके किए जाते हैं.
उपयोगकर्ता सीधे टेस्ट बाइनरी भी एक्ज़ीक्यूट कर सकते हैं. इसकी अनुमति है, लेकिन इसका प्रचार नहीं किया जाता है. क्योंकि ऐसा करने पर, नीचे दिए गए मैंडेट का पालन नहीं होगा.
टेस्ट, हर्मेटिक होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ वे संसाधन ऐक्सेस करने चाहिए जिन पर वे डिपेंडेंसी के तौर पर जुड़े हों. अगर टेस्ट सही तरीके से हर्मेटिक नहीं हैं, तो वे पुराने तरीके से फिर से जनरेट किए जा सकने वाले नतीजे नहीं देते. यह गलती
कैंपेन का मकसद
इस पेज का मकसद औपचारिक तौर पर, Bazel टेस्ट के लिए रनटाइम एनवायरमेंट और उम्मीद के मुताबिक व्यवहार तय करना है. यह टेस्ट रनर और बिल्ड सिस्टम के लिए भी ज़रूरी शर्तें लागू करेगा.
टेस्ट एनवायरमेंट स्पेसिफ़िकेशन से, टेस्ट के लेखक तय न किए गए व्यवहार पर भरोसा करने से बचते हैं. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने के तरीके में ज़्यादा बदलाव करने की आज़ादी मिलती है. इस तरीके में कुछ ऐसी कमियां हैं जो मौजूदा समय में कई जांचों को पास होने देती हैं, भले ही ये ठीक तरह से हर्मेटिक, तय करने वाले, और फिर से दिलचस्पी न लेने वाले डिवाइस हों.
यह पेज मान्य और आधिकारिक, दोनों तरह के होने के लिए बनाया गया है. अगर इस जानकारी और टेस्ट रनर के लागू किए गए व्यवहार में अंतर है, तो इस स्पेसिफ़िकेशन को प्राथमिकता दी जाएगी.
सुझाई गई जानकारी
"ज़रूरी है", "नहीं करना है", "ज़रूरी", "करना चाहिए", "नहीं", "चाहिए", "नहीं", "सुझाया गया", "किया जा सकता है", और "ज़रूरी नहीं" का मतलब ऐसे समझा जाना चाहिए जैसा आईईटीएफ़ आरएफ़सी 2119 में बताया गया है.
टेस्ट का मकसद
Bazel टेस्ट का मकसद, डेटा स्टोर करने की जगह में चेक की गई सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना होता है. (इस पेज पर, "सोर्स फ़ाइलें" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी गई अन्य सभी चीज़ें शामिल होती हैं.) एक उपयोगकर्ता ऐसे अलग-अलग वैरिएंट का दावा करने के लिए टेस्ट लिखता है जिसके इस्तेमाल को बनाए रखने की वह उम्मीद करता है. अन्य उपयोगकर्ता, बाद में जांच करके यह पता लगाते हैं कि वैरिएंट तो नहीं हुआ. अगर यह टेस्ट, सोर्स फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी दूसरे वैरिएबल पर निर्भर करता है, तो इसकी वैल्यू कम हो जाती है. ऐसा इसलिए होता है, क्योंकि बाद वाले उपयोगकर्ता यह पक्का नहीं कर सकते कि टेस्ट पास होने से रोकने पर उनके बदलावों में गलती है.
इसलिए, टेस्ट का नतीजा सिर्फ़ इन चीज़ों पर निर्भर होना चाहिए:
- ऐसी सोर्स फ़ाइलें जिन पर टेस्ट की डिपेंडेंसी तय की गई है
- बिल्ड सिस्टम के प्रॉडक्ट, जिन पर टेस्ट की डिपेंडेंसी बताई गई है
- ऐसे संसाधन जिनके व्यवहार की गारंटी टेस्ट रनर से लगातार बनी रहती है
फ़िलहाल, ऐसा व्यवहार लागू नहीं किया जाता. हालांकि, टेस्ट रनर के पास आने वाले समय में इस तरह की नीति को लागू करने का अधिकार है.
बिल्ड सिस्टम की भूमिका
जांच के नियम, बाइनरी नियमों से मिलते-जुलते होते हैं. ऐसे में हर नियम के लिए एक एक्ज़ीक्यूटेबल प्रोग्राम होना ज़रूरी है. कुछ भाषाओं के लिए, यह एक स्टब प्रोग्राम है. इसमें भाषा के आधार पर, टेस्ट कोड के साथ इस्तेमाल किया जाता है. जांच के नियमों से अन्य आउटपुट भी जनरेट होने चाहिए. टेस्ट रनर को, प्राइमरी टेस्ट के लिए एक्ज़ीक्यूटेबल फ़ाइल के अलावा, रनफ़ाइल के मेनिफ़ेस्ट की ज़रूरत होगी. इसमें वे इनपुट फ़ाइलें शामिल होंगी जिन्हें रनटाइम के दौरान टेस्ट के लिए उपलब्ध कराया जाना चाहिए. साथ ही, इसे टेस्ट के टाइप, साइज़, और टैग की जानकारी की भी ज़रूरत हो सकती है.
बिल्ड सिस्टम, कोड और डेटा डिलीवर करने के लिए रनफ़ाइल का इस्तेमाल कर सकता है. (इसका इस्तेमाल ऑप्टिमाइज़ेशन के तौर पर, हर जांच की बाइनरी को छोटा करने के लिए किया जा सकता है. ऐसा, जांचों के बीच फ़ाइलें शेयर करके किया जा सकता है, जैसे कि डाइनैमिक लिंकिंग का इस्तेमाल करके.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई एक्ज़ीक्यूटेबल फ़ाइल, सोर्स या आउटपुट ट्री में ऐब्सलूट लोकेशन के हार्डकोड किए गए रेफ़रंस के बजाय, टेस्ट रनर से मिले रनफ़ाइल इमेज से लोड की जाए.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक प्रोग्राम है जिसे execve() की मदद से शुरू किया जा सकता है. टेस्ट चलाने के दूसरे तरीके भी हो सकते हैं; उदाहरण के लिए,
IDE, प्रोसेस के दौरान Java टेस्ट को चलाने की अनुमति दे सकता है. हालांकि, स्टैंडअलोन प्रोसेस के तौर पर टेस्ट चलाने के नतीजे को आधिकारिक माना जाना चाहिए. अगर
कोई परीक्षण प्रक्रिया पूरी हो जाती है और शून्य कोड के साथ सामान्य रूप से खत्म हो जाती है, तो परीक्षण पास हो गया है. किसी भी अन्य नतीजे को टेस्ट फ़ेलियर माना जाता है. खास
तौर पर, स्टडआउट के लिए PASS या FAIL में से किसी भी स्ट्रिंग को लिखने का, टेस्ट रनर के लिए कोई खास
मतलब नहीं होता है.
अगर किसी टेस्ट को लागू होने में बहुत ज़्यादा समय लगता है, संसाधन की सीमा पार हो जाती है या टेस्ट रनर को किसी पाबंदी वाले व्यवहार का पता चलता है, तो हो सकता है कि टेस्ट बंद कर दिया जाए और टेस्ट को फ़ेल माना जाए. टेस्ट प्रोसेस या किसी बच्चे को सिग्नल भेजने के बाद, रनर को यह नहीं बताना चाहिए कि टेस्ट पास हो गया है.
पूरे टेस्ट टारगेट (अलग-अलग तरीकों या टेस्ट को नहीं) को पूरा होने तक सीमित
समय दिया जाता है. टेस्ट की समयसीमा, नीचे दी गई टेबल के मुताबिक उसके timeout एट्रिब्यूट पर आधारित है:
| टाइम आउट | समय सीमा (सेकंड) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| अनंत | 3600 |
जो टेस्ट साफ़ तौर पर टाइम आउट की जानकारी नहीं देते हैं उनका size टेस्ट के आधार पर इस तरह से तय होता है:
| साइज़ | शामिल टाइम आउट लेबल |
|---|---|
| छोटा | छोटा |
| medium | मध्यम |
| बड़ा | लंबा |
| विशाल | अनंत |
किसी "बड़े" टेस्ट को चलने के लिए 900 सेकंड दिए जाएंगे. हालांकि, इसमें टाइम आउट की कोई खास सेटिंग नहीं होगी. "कम" टाइम आउट वाले "मीडियम" टेस्ट को 60 सेकंड मिलेंगे.
timeout के उलट, size अतिरिक्त रूप से यह तय करता है कि स्थानीय तौर पर टेस्ट करते समय, अन्य संसाधनों (जैसे कि रैम) का सबसे ज़्यादा इस्तेमाल किया गया है या नहीं. इसकी जानकारी सामान्य डेफ़िनिशन में दी गई है.
size और timeout लेबल के सभी कॉम्बिनेशन कानूनी होते हैं. इसलिए, "बहुत ज़्यादा" टेस्ट के बारे में एलान किया जा सकता है कि टाइम आउट की अवधि "छोटा" हो. शायद यह कुछ वाकई भयानक काम
बहुत जल्दी कर देगा.
टेस्ट, टाइम आउट की परवाह किए बिना मनचाहे तरीके से तेज़ी से नतीजे दे सकते हैं. अगर टाइम आउट बहुत ज़्यादा हो, तो उसके ख़िलाफ़ कोई कार्रवाई नहीं की जाएगी. हालांकि, इसके लिए चेतावनी भी दी जा सकती है: आपको आम तौर पर टाइम आउट को जितना हो सके उतना कम सेट करना चाहिए. साथ ही, इस दौरान कोई गड़बड़ी भी नहीं होनी चाहिए.
जब सिस्टम को मैन्युअल तौर पर धीमा माना जाता है, तब टेस्ट टाइम आउट को --test_timeout बेज़ेल फ़्लैग से बदला जा सकता है. --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 |
सेट नहीं किया गया | ज़रूरी है |
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 |
लिखने वाली डायरेक्ट्री में किसी निजी फ़ाइल का ऐब्सलूट पाथ (Logsplitter प्रोटोबफ़र लॉग लिखने के लिए इस्तेमाल किया जाता है) | ज़रूरी नहीं |
TEST_PREMATURE_EXIT_FILE |
लिखने वाली डायरेक्ट्री में किसी निजी फ़ाइल का ऐब्सलूट पाथ (exit() पर कॉल करने के लिए इस्तेमाल किया जाता है) |
ज़रूरी नहीं |
TEST_RANDOM_SEED |
अगर --runs_per_test विकल्प का इस्तेमाल किया जाता है, तो हर बार टेस्ट के लिए TEST_RANDOM_SEED को एक से शुरू होने वाले run number (एक से शुरू) पर सेट किया जाता है. |
ज़रूरी नहीं |
TEST_RUN_NUMBER |
अगर --runs_per_test विकल्प का इस्तेमाल किया जाता है, तो हर बार टेस्ट के लिए TEST_RUN_NUMBER को एक से शुरू होने वाले run number (एक से शुरू) पर सेट किया जाता है. |
ज़रूरी नहीं |
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 |
वह जगह जहां पर टेस्ट की कार्रवाइयों को, टेस्ट नतीजे की एक्सएमएल आउटपुट फ़ाइल लिखनी चाहिए. नहीं तो, Bazel, टेस्ट कार्रवाई के तौर पर टेस्ट लॉग को रैप करते हुए, एक डिफ़ॉल्ट एक्सएमएल आउटपुट फ़ाइल जनरेट करता है. एक्सएमएल स्कीमा, 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 केबी <= rlim <= 8192 केबी |
प्रोसेस की शुरुआत में लगने वाला समय (times() से मिला डेटा) और संसाधन के इस्तेमाल
(जैसा कि getrusage() ने दिखाया है) की जानकारी नहीं दी गई है.
शेड्यूल करने की शुरुआती नीति और प्राथमिकता की जानकारी नहीं है.
होस्ट सिस्टम की भूमिका
टेस्ट रनर के सीधे कंट्रोल में उपयोगकर्ता के कॉन्टेक्स्ट के अलावा, जिस ऑपरेटिंग सिस्टम पर टेस्ट चलाया जाता है उसे कुछ प्रॉपर्टी के हिसाब से टेस्ट चलाना होता है.
फ़ाइल सिस्टम
टेस्ट के ज़रिए देखी गई रूट डायरेक्ट्री, असली रूट डायरेक्ट्री हो सकती है और नहीं भी.
/proc को माउंट किया जाएगा.
सभी बिल्ड टूल, /usr से नीचे के ऐब्सलूट पाथ पर मौजूद होने चाहिए जिसका इस्तेमाल लोकल इंस्टॉलेशन में होता है.
हो सकता है कि /home से शुरू होने वाले पाथ उपलब्ध न हों. टेस्ट को ऐसे किसी भी पाथ को ऐक्सेस नहीं करना चाहिए.
/tmp लिखा जा सकेगा, लेकिन टेस्ट में इन पाथ का इस्तेमाल करने से बचना चाहिए.
टेस्ट को यह नहीं मानना चाहिए कि उनके खास इस्तेमाल के लिए, कोई स्थायी पाथ उपलब्ध है.
टेस्ट में यह नहीं मानना चाहिए कि माउंट किए गए किसी फ़ाइल सिस्टम के लिए, atime चालू हैं या नहीं.
उपयोगकर्ता और समूह
उपयोगकर्ता का रूट, कोई भी नहीं, और यूनिटटेस्ट मौजूद होना चाहिए. ग्रुप रूट, किसी का भी नहीं, और इंजी होना ज़रूरी है.
टेस्ट को नॉन-रूट उपयोगकर्ता के तौर पर एक्ज़ीक्यूट किया जाना चाहिए. ग्रुप आईडी के लिए, असली और असरदार यूज़र आईडी एक जैसे होने चाहिए. इसके अलावा, मौजूदा यूज़र आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप के नाम की जानकारी नहीं दी गई है. पूरक समूह आईडी के सेट की जानकारी नहीं दी गई है.
मौजूदा यूज़र आईडी और ग्रुप आईडी में एक जैसे नाम होने चाहिए, जिन्हें getpwuid() और getgrgid() का इस्तेमाल करके फिर से हासिल किया जा सके. ऐसा हो सकता है कि पूरक ग्रुप आईडी
के लिए भी यह सही न हो.
मौजूदा उपयोगकर्ता के पास होम डायरेक्ट्री होनी चाहिए. हो सकता है कि यह लिखने लायक न हो. जांचों को उसमें लिखने की कोशिश नहीं करनी चाहिए.
नेटवर्किंग
होस्टनेम की जानकारी नहीं दी गई है. इसमें बिंदु हो भी सकता है या नहीं भी हो सकता है. होस्टनेम का समाधान करने से मौजूदा होस्ट का आईपी पता मिलना चाहिए. पहले बिंदु के बाद होस्टनेम कट को हल करने में भी काम होना चाहिए. होस्टनेम लोकलहोस्ट का समाधान करना ज़रूरी है.
अन्य संसाधन
जांच के लिए कम से कम एक सीपीयू कोर की ज़रूरत होती है. अन्य उपलब्ध हो सकते हैं, लेकिन इसकी गारंटी नहीं है. इस कोर के अन्य प्रदर्शन पहलुओं के बारे में नहीं बताया गया है. जांच के नियम में "cpu:n" (जहां n एक पॉज़िटिव संख्या है) टैग जोड़कर, ज़्यादा संख्या में सीपीयू (CPU) की संख्या के लिए रिज़र्वेशन को बढ़ाया जा सकता है. अगर किसी मशीन में अनुरोध किए गए से कम सीपीयू कोर हैं, तो भी 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 में मौजूद फ़ाइलों को क्लाउड पर ठीक करती हैं. इसलिए, TEST_TMPDIR के बाहर फ़ाइलें बनाने के बाद भी इनका इस्तेमाल किया जा सकता है.
टेस्ट को रनफ़ाइल तरीके या प्रोग्राम चलाने के माहौल के दूसरे हिस्सों से इनपुट ऐक्सेस करने चाहिए. इनका मकसद खास तौर पर इनपुट फ़ाइलों को उपलब्ध कराना है.
टेस्ट को खुद के एक्ज़ीक्यूटेबल की जगह से अनुमानित पाथ पर, बिल्ड सिस्टम के दूसरे आउटपुट को ऐक्सेस नहीं करना चाहिए.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें हैं, सिंबॉलिक लिंक हैं या मिक्स्चर हैं. रनफ़ाइल ट्री में, डायरेक्ट्री के लिए सिमलिंक हो सकते हैं.
टेस्ट में, रनफ़ाइल ट्री में .. कॉम्पोनेंट वाले पाथ का इस्तेमाल करने से बचना चाहिए.
रनफ़ाइल ट्री में कोई भी डायरेक्ट्री, फ़ाइल या सिमलिंक नहीं लिखा जाना चाहिए. इसमें वे पाथ भी शामिल हैं जिनमें सिमलिंक को ट्रैवर्स किया जाता है. (इसका मतलब यह है कि शुरुआती
डायरेक्ट्री को लिखा जा सकता है.) जांच में यह नहीं मानना चाहिए कि रनफ़ाइल का कोई भी हिस्सा लिखने लायक है या उसका मालिकाना हक मौजूदा उपयोगकर्ता के पास है (उदाहरण के लिए, chmod और chgrp काम नहीं कर सकते).
टेस्ट के चलने के दौरान रनफ़ाइल ट्री (इसमें सिमलिंक को पार करने वाले पाथ शामिल हैं) में बदलाव नहीं होना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में किसी भी तरह का बदलाव नहीं होना चाहिए. इसका असर रनफ़ाइल ट्री में पाथ के समाधान के नतीजे पर पड़ता है.
समय से पहले बाहर निकलने के बारे में जानकारी पाने के लिए, टेस्ट शुरू होने पर TEST_PREMATURE_EXIT_FILE के बताए गए पाथ पर एक फ़ाइल बना सकता है और बाहर निकलने पर उसे हटा सकता है. अगर टेस्ट पूरा होने पर बैजल को फ़ाइल दिखती है, तो यह मान लिया जाएगा कि टेस्ट समय से पहले बंद हो गया है. साथ ही, उसे 'फ़ेल हो गया' के तौर पर मार्क किया जाता है.
टैग कन्वेंशन
जांच के नियमों में मौजूद कुछ टैग का एक खास मतलब होता है. tags एट्रिब्यूट पर, Bazel बिल्ड एन्साइक्लोपीडिया भी देखें.
| टैग करें | मतलब |
|---|---|
exclusive |
एक ही समय पर कोई और टेस्ट न चलाएं |
external |
टेस्ट में बाहरी निर्भरता है; टेस्ट को कैश मेमोरी में सेव करने की सुविधा बंद करें |
large |
test_suite कन्वेंशन; बड़े टेस्ट का सुइट |
manual * |
:..., :* या :all जैसे वाइल्डकार्ड टारगेट पैटर्न में टेस्ट टारगेट शामिल न करें |
medium |
test_suite कन्वेंशन; मीडियम टेस्ट का सुइट |
small |
test_suite कन्वेंशन; छोटे टेस्ट का सुइट |
smoke |
test_suite कन्वेंशन; इसका मतलब है कि इसे वर्शन कंट्रोल सिस्टम में कोड बदलने से पहले चलाया जाना चाहिए |
रनफ़ाइलें
नीचे दी गई टेबल में, मान लें कि *_binary() नियम है जिसे
//foo/bar:unittest लेबल किया गया है. साथ ही, इसमें
//deps/server:server लेबल वाले नियम पर रन-टाइम डिपेंडेंसी है.
जगह
टारगेट //foo/bar:unittest के लिए रनफ़ाइल डायरेक्ट्री, $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles डायरेक्ट्री है. इस पाथ को runfiles_dir कहा जाता है.
डिपेंडेंसी
रन फ़ाइल डायरेक्ट्री को *_binary() नियम के कंपाइल-टाइम डिपेंडेंसी के तौर पर तय किया गया है. रनफ़ाइल डायरेक्ट्री अपने आप में BUILD फ़ाइलों के सेट पर निर्भर करती है, जो *_binary() नियम या उसके किसी भी कंपाइल-टाइम या रन-टाइम डिपेंडेंसी पर असर डालती है. सोर्स फ़ाइलों में बदलाव करने से रनफ़ाइल डायरेक्ट्री के स्ट्रक्चर पर कोई असर नहीं पड़ता. इस वजह से, फिर से कोई इमारत नहीं बनाई जाती.
विषय सूची
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल हैं:
- रन-टाइम डिपेंडेंसी के लिए सिमलिंक: हर एक आउटपुट-फ़ाइल और Commandनियम, जो
*_binary()नियम की रन-टाइम डिपेंडेंसी है, रनफ़ाइल डायरेक्ट्री में एक सिमलिंक के तौर पर दिखाया जाता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_nameहै. उदाहरण के लिए, सर्वर के सिमलिंक को$(WORKSPACE)/deps/server/serverऔर पूरे पाथ का नाम$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverहोगा. सिमलिंक का डेस्टिनेशन, OUTFile या Command बटन का OUTFileName() होता है. इसे ऐब्सलूट पाथ के तौर पर दिखाया जाता है. इसलिए, सिमलिंक का डेस्टिनेशन$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकता है. - सब-रनफ़ाइल के लिए सिमलिंक: हर
*_binary()Z के लिए, जो*_binary()C की रन-टाइम डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में Z की रनफ़ाइल का दूसरा लिंक होता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिमलिंक का टारगेट रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सब-प्रोग्राम एक ही रनफ़ाइल डायरेक्ट्री को शेयर करते हैं.