टेस्ट को चलाने के लिए इस्तेमाल किए जाने वाले एनवायरमेंट के बारे में पूरी जानकारी.
बैकग्राउंड
Bazel BUILD भाषा में ऐसे नियम शामिल होते हैं जिनका इस्तेमाल, कई भाषाओं में अपने-आप चलने वाले जांच प्रोग्राम तय करने के लिए किया जा सकता है.
टेस्ट, bazel test का इस्तेमाल करके चलाए जाते हैं.
उपयोगकर्ता, सीधे तौर पर टेस्ट बाइनरी भी चला सकते हैं. ऐसा करने की अनुमति है, लेकिन हम इसकी पुष्टि नहीं करते. ऐसा इसलिए, क्योंकि इस तरह के इनवोकेशन से नीचे दी गई ज़रूरी शर्तों का पालन नहीं होगा.
टेस्ट हर्मेटिक होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ उन संसाधनों का ऐक्सेस लेना चाहिए जिन पर उनकी डिपेंडेंसी है. अगर टेस्ट सही तरीके से नहीं किए जाते हैं, तो वे पुराने नतीजे नहीं दिखाते. यह समस्या, गड़बड़ी का पता लगाने (यह तय करना कि किस बदलाव की वजह से टेस्ट पूरा नहीं हो पाया), रिलीज़ इंजीनियरिंग की ऑडिटिंग, और टेस्ट के लिए संसाधनों को अलग-अलग रखने के लिए बड़ी समस्या हो सकती है. अपने-आप टेस्ट करने वाले फ़्रेमवर्क को किसी सर्वर को डीडीओएस नहीं करना चाहिए, क्योंकि कुछ टेस्ट उससे बात करते हैं.
मकसद
इस पेज का मकसद, Bazel टेस्ट के लिए रनटाइम एनवायरमेंट को आधिकारिक तौर पर सेट अप करना और उनके काम करने के तरीके के बारे में बताना है. इससे टेस्ट रनर और बिल्ड सिस्टम पर भी ज़रूरी शर्तें लागू होंगी.
टेस्ट एनवायरमेंट की खास जानकारी से, टेस्ट के लेखकों को ऐसे व्यवहार पर भरोसा करने से बचने में मदद मिलती है जिसकी जानकारी नहीं दी गई है. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने से जुड़े बदलाव करने में ज़्यादा आसानी होती है. इस स्पेसिफ़िकेशन में कुछ ऐसे गड़बड़ियों को ठीक किया गया है जिनकी वजह से, फ़िलहाल कई टेस्ट पास हो जाते हैं. हालांकि, ये टेस्ट पूरी तरह से हेर्मेटिक, डिटरमिनिस्टिक, और रीएंट्रेंट नहीं होते.
इस पेज का मकसद, नियमों के मुताबिक और आधिकारिक जानकारी देना है. अगर इस स्पेसिफ़िकेशन और टेस्ट रनर के लागू किए गए व्यवहार में अंतर है, तो स्पेसिफ़िकेशन को प्राथमिकता दी जाती है.
प्रस्तावित स्पेसिफ़िकेशन
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" कीवर्ड का मतलब, IETF RFC 2119 में बताए गए मुताबिक है.
टेस्ट का मकसद
Bazel टेस्ट का मकसद, रिपॉज़िटरी में चेक की गई सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है. (इस पेज पर, "सोर्स फ़ाइलों" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी गई कोई भी अन्य चीज़ शामिल होती है.) एक उपयोगकर्ता, किसी ऐसे इनवैरिएंट के लिए जांच लिखता है जिसे बनाए रखने की उम्मीद है. अन्य उपयोगकर्ता, बाद में टेस्ट चलाकर यह जांच करते हैं कि इनवैरिएंट का उल्लंघन हुआ है या नहीं. अगर जांच, सोर्स फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी अन्य वैरिएबल पर निर्भर करती है, तो इसकी वैल्यू कम हो जाती है. ऐसा इसलिए होता है, क्योंकि बाद में जब जांच पास नहीं होती है, तो उपयोगकर्ता यह पक्का नहीं कर पाते कि उनके बदलावों की वजह से ऐसा हुआ है.
इसलिए, किसी टेस्ट का नतीजा सिर्फ़ इन पर निर्भर होना चाहिए:
- सोर्स फ़ाइलें, जिन पर टेस्ट की डिपेंडेंसी है
- बिल्ड सिस्टम के ऐसे प्रॉडक्ट जिन पर टेस्ट की डिपेंडेंसी है
- ऐसे संसाधन जिनके व्यवहार में कोई बदलाव नहीं होता
फ़िलहाल, ऐसा नहीं किया जा रहा है. हालांकि, टेस्ट रन करने वाले लोगों के पास, आने वाले समय में इस तरह की नीति को लागू करने का अधिकार सुरक्षित है.
बिल्ड सिस्टम की भूमिका
टेस्ट नियम, बाइनरी नियमों से मिलते-जुलते होते हैं. इनमें से हर नियम से एक ऐसा प्रोग्राम बनना चाहिए जिसे चलाया जा सके. कुछ भाषाओं के लिए, यह एक स्टब प्रोग्राम है, जो भाषा के हिसाब से हर्नेस को टेस्ट कोड के साथ जोड़ता है. जांच के नियमों से अन्य आउटपुट भी मिलने चाहिए. टेस्ट रनर को मुख्य टेस्ट एक्सीक्यूटेबल के अलावा, runfiles का मेनिफ़ेस्ट भी चाहिए. ये इनपुट फ़ाइलें होती हैं, जिन्हें रनटाइम के दौरान टेस्ट के लिए उपलब्ध कराया जाना चाहिए. साथ ही, टेस्ट के टाइप, साइज़, और टैग की जानकारी भी ज़रूरी हो सकती है.
बिल्ड सिस्टम, कोड के साथ-साथ डेटा डिलीवर करने के लिए, रनफ़ाइलों का इस्तेमाल कर सकता है. (इसका इस्तेमाल ऑप्टिमाइज़ेशन के तौर पर किया जा सकता है, ताकि हर टेस्ट बाइनरी को छोटा बनाया जा सके. इसके लिए, सभी टेस्ट में फ़ाइलें शेयर की जा सकती हैं. जैसे, डाइनैमिक लिंकिंग का इस्तेमाल करके.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई एक्सीक्यूटेबल, सोर्स या आउटपुट ट्री में ऐब्सलूट जगहों के लिए हार्डकोड किए गए रेफ़रंस के बजाय, टेस्ट रनर की दी गई runfiles इमेज के ज़रिए इन फ़ाइलों को लोड करे.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक प्रोग्राम होता है जिसे execve() के साथ शुरू किया जा सकता है. टेस्ट को चलाने के अन्य तरीके भी हो सकते हैं. उदाहरण के लिए, किसी IDE में प्रोसेस के दौरान Java टेस्ट चलाए जा सकते हैं. हालांकि, टेस्ट को स्टैंडअलोन प्रोसेस के तौर पर चलाने के नतीजे को आधिकारिक माना जाना चाहिए. अगर जांच की प्रोसेस पूरी हो जाती है और सामान्य तौर पर, 'बाहर निकलने का कोड' शून्य पर सेट हो जाता है, तो इसका मतलब है कि जांच पूरी हो गई है. किसी भी अन्य नतीजे को जांच में गड़बड़ी माना जाता है. खास तौर पर, स्टैंडर्ड आउटपुट में 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 देखें. इनकी मदद से, शर्ड करने की सुविधा की जांच करने की सुविधा चालू की जा सकती है. जब sharding चालू होती है, तो हर स्hard के लिए एक बार टेस्ट रनर लॉन्च किया जाता है. एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS, शार्ड की संख्या है और TEST_SHARD_INDEX, शार्ड का इंडेक्स है, जो 0 से शुरू होता है. रनर इस जानकारी का इस्तेमाल यह चुनने के लिए करते हैं कि कौनसे टेस्ट चलाए जाएं. उदाहरण के लिए, राउंड-रोबिन रणनीति का इस्तेमाल करके. सभी टेस्ट रनर, टास्क को अलग-अलग हिस्सों में बांटने की सुविधा के साथ काम नहीं करते. अगर कोई रनर, शर्डिंग की सुविधा देता है, तो उसे TEST_SHARD_STATUS_FILE से तय की गई फ़ाइल की पिछली बार बदलाव करने की तारीख को बनाना या अपडेट करना होगा. अगर --incompatible_check_sharding_support चालू है, तो बज़ल टेस्ट पास नहीं करेगा.
शुरुआती शर्तें
टेस्ट को लागू करते समय, टेस्ट रनर को कुछ शुरुआती शर्तें तय करनी होंगी.
टेस्ट रनर को हर टेस्ट को 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 प्रोटोबबल लॉग को लिखने के लिए किया जाता है) | ज़रूरी नहीं |
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 |
runfiles ट्री के बेस का ऐब्सलूट पाथ | ज़रूरी है |
TEST_TOTAL_SHARDS |
अगर sharding का इस्तेमाल किया जाता है, तो कुल
shard count |
ज़रूरी नहीं |
TEST_TMPDIR |
लिखने की अनुमति वाली निजी डायरेक्ट्री का ऐब्सलूट पाथ | ज़रूरी है |
TEST_WORKSPACE |
लोकल रिपॉज़िटरी के वर्कस्पेस का नाम | ज़रूरी नहीं |
TEST_UNDECLARED_OUTPUTS_DIR |
लिखने की अनुमति वाली निजी डायरेक्ट्री का ऐब्सलूट पाथ (जिसका इस्तेमाल, एलान न किए गए टेस्ट आउटपुट को लिखने के लिए किया जाता है) | ज़रूरी नहीं |
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 में लिखा जा सकता है, लेकिन टेस्ट में इन पाथ का इस्तेमाल नहीं किया जाना चाहिए.
टेस्ट को यह नहीं मानना चाहिए कि उनके खास इस्तेमाल के लिए कोई कॉन्स्टेंट पाथ उपलब्ध है.
टेस्ट में यह नहीं माना जाना चाहिए कि माउंट किए गए किसी भी फ़ाइल सिस्टम के लिए, atimes चालू हैं.
उपयोगकर्ता और समूह
उपयोगकर्ता root, nobody, और unittest मौजूद होने चाहिए. root, nobody, और eng ग्रुप मौजूद होने चाहिए.
टेस्ट, नॉन-रूट उपयोगकर्ता के तौर पर चलाए जाने चाहिए. असल और असरदार यूज़र आईडी एक जैसे होने चाहिए. ग्रुप आईडी के लिए भी यही बात लागू होती है. इसके अलावा, मौजूदा उपयोगकर्ता आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप का नाम नहीं बताया गया है. पूरक ग्रुप आईडी का सेट तय नहीं किया गया है.
मौजूदा उपयोगकर्ता आईडी और ग्रुप आईडी के नाम एक जैसे होने चाहिए. इन्हें getpwuid() और getgrgid() की मदद से वापस पाया जा सकता है. ऐसा हो सकता है कि यह बात, पूरक ग्रुप आईडी के लिए लागू न हो.
मौजूदा उपयोगकर्ता के पास होम डायरेक्ट्री होनी चाहिए. हो सकता है कि उसमें बदलाव न किया जा सके. टेस्ट को इसमें लिखने की कोशिश नहीं करनी चाहिए.
नेटवर्किंग
होस्टनेम नहीं दिया गया है. इसमें बिंदु हो सकता है या नहीं भी. होस्टनेम को रिज़ॉल्व करने पर, मौजूदा होस्ट का आईपी पता दिखना चाहिए. पहले बिंदु के बाद, होस्टनेम को काटकर भी पता लगाया जा सकता है. होस्टनेम localhost को रिज़ॉल्व करना ज़रूरी है.
अन्य संसाधन
टेस्ट के लिए कम से कम एक सीपीयू कोर दिया जाता है. ऐसा हो सकता है कि अन्य विकल्प भी उपलब्ध हों, लेकिन इसकी कोई गारंटी नहीं है. इस कोर की परफ़ॉर्मेंस के अन्य पहलुओं के बारे में नहीं बताया गया है. किसी टेस्ट नियम में "cpu:n" टैग (जहां n एक धनात्मक संख्या है) जोड़कर, सीपीयू कोर की संख्या को ज़्यादा किया जा सकता है. अगर किसी मशीन में, अनुरोध किए गए सीपीयू कोर से कम सीपीयू कोर हैं, तो भी Bazel टेस्ट चलाएगा. अगर कोई टेस्ट शर्डिंग का इस्तेमाल करता है, तो हर शर्ड के लिए यहां बताई गई सीपीयू कोर की संख्या रिज़र्व की जाएगी.
टेस्ट, सबप्रोसेस बना सकते हैं, लेकिन ग्रुप या सेशन प्रोसेस नहीं कर सकते.
किसी टेस्ट में, इनपुट फ़ाइलों की संख्या सीमित होनी चाहिए. यह सीमा बदल सकती है, लेकिन फ़िलहाल यह 10 हज़ार इनपुट की रेंज में है.
समय और तारीख
मौजूदा समय और तारीख की जानकारी नहीं दी गई है. सिस्टम के टाइमज़ोन की जानकारी नहीं दी गई है.
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 से बाहर फ़ाइलें बनाते हों, फिर भी इनका इस्तेमाल किया जा सकता है.
टेस्ट को runfiles मेकेनिज्म या रनटाइम एनवायरमेंट के उन हिस्सों के ज़रिए इनपुट ऐक्सेस करने चाहिए जिनका मकसद खास तौर पर इनपुट फ़ाइलें उपलब्ध कराना है.
टेस्ट को अपने एक्सीक्यूटेबल की जगह से अनुमानित पाथ पर, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं करना चाहिए.
यह नहीं बताया गया है कि रनफ़ाइल्स ट्री में रेगुलर फ़ाइलें, सिंबल लिंक या दोनों शामिल हैं. रनफ़ाइल्स ट्री में डायरेक्ट्री के लिए सिमलंक हो सकते हैं.
टेस्ट में, रनफ़ाइल ट्री में .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए.
runfiles ट्री में मौजूद किसी भी डायरेक्ट्री, फ़ाइल या सिंबललिंक में लिखने की अनुमति नहीं होनी चाहिए. इसमें ऐसे पाथ भी शामिल हैं जो सिंबललिंक को ट्रैवर्स करते हैं. (इसका मतलब है कि शुरुआती वर्किंग डायरेक्ट्री में लिखने की अनुमति नहीं होनी चाहिए.) जांचों में यह नहीं माना जाना चाहिए कि रनफ़ाइलों का कोई हिस्सा लिखने लायक है या उसका मालिकाना हक मौजूदा उपयोगकर्ता के पास है. उदाहरण के लिए, chmod और chgrp काम न कर सकते.
जांच के दौरान, रनफ़ाइल ट्री (इसमें सिमलंक के ज़रिए ट्रैवर्स करने वाले पाथ शामिल हैं) में कोई बदलाव नहीं होना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में ऐसा कोई बदलाव नहीं होना चाहिए जिससे runfiles ट्री में किसी पाथ को हल करने के नतीजे पर असर पड़े.
ऐप्लिकेशन के जल्दी बंद होने का पता लगाने के लिए, टेस्ट शुरू होने पर TEST_PREMATURE_EXIT_FILE के तय किए गए पाथ पर एक फ़ाइल बनाई जा सकती है और ऐप्लिकेशन बंद होने पर उसे हटाया जा सकता है. अगर जांच पूरी होने पर Bazel को फ़ाइल दिखती है, तो यह मान लिया जाएगा कि जांच समय से पहले खत्म हो गई है और इसे 'असफल' के तौर पर मार्क कर दिया जाएगा.
टैग के लिए नाम तय करने के तरीके
टेस्ट के नियमों में कुछ टैग का खास मतलब होता है. tags एट्रिब्यूट के बारे में, Bazel Build Encyclopedia भी देखें.
| टैग | मतलब |
|---|---|
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 डायरेक्ट्री है. इस पाथ को runfiles_dir कहा जाता है.
डिपेंडेंसी
runfiles डायरेक्ट्री को *_binary() नियम के लिए, कंपाइल के समय की डिपेंडेंसी के तौर पर घोषित किया गया है. runfiles डायरेक्ट्री, BUILD फ़ाइलों के सेट पर निर्भर करती है. ये फ़ाइलें, *_binary() नियम या उसके किसी भी कंपाइल-टाइम या रन-टाइम डिपेंडेंसी पर असर डालती हैं. सोर्स फ़ाइलों में बदलाव करने से, रनफ़ाइल डायरेक्ट्री के स्ट्रक्चर पर कोई असर नहीं पड़ता. इसलिए, रीबिल्ड करने की प्रोसेस शुरू नहीं होती.
सामग्री
runfiles डायरेक्ट्री में ये चीज़ें शामिल होती हैं:
- रन-टाइम डिपेंडेंसी के लिए सिमलिन्क:
*_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()C की रन-टाइम डिपेंडेंसी वाली हर*_binary()Z के लिए, C की रनफ़ाइल डायरेक्ट्री में Z की रनफ़ाइलों का दूसरा लिंक होता है. सिंबललिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिंबल लिंक का टारगेट, रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सब-प्रोग्राम एक ही रनफ़ाइल डायरेक्ट्री शेयर करते हैं.