टेस्ट को चलाने के लिए इस्तेमाल किए जाने वाले एनवायरमेंट के बारे में पूरी जानकारी.
बैकग्राउंड
बेज़ल बिल्ड भाषा में ऐसे नियम शामिल हैं जिनका इस्तेमाल करके अपने-आप कई भाषाओं में टेस्ट प्रोग्राम उपलब्ध करा सकता है.
जांच, bazel test का इस्तेमाल करके की जाती हैं.
उपयोगकर्ता, सीधे तौर पर टेस्ट बाइनरी भी चला सकते हैं. ऐसा करने की अनुमति है, लेकिन हम इसकी पुष्टि नहीं करते. ऐसा इसलिए, क्योंकि इस तरह के इनवोकेशन से नीचे दी गई ज़रूरी शर्तों का पालन नहीं होगा.
टेस्ट हर्मेटिक होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ उन संसाधनों का ऐक्सेस होना चाहिए तय की गई डिपेंडेंसी है. अगर परीक्षणों को सही तरीके से हर्मेटिक नहीं बनाया गया हो तो वे ऐतिहासिक तौर पर फिर से जनरेट किए जा सकने वाले नतीजे नहीं देते. यह समस्या, गड़बड़ी का पता लगाने (यह तय करना कि किस बदलाव की वजह से टेस्ट पूरा नहीं हो पाया), रिलीज़ इंजीनियरिंग की ऑडिटिंग, और टेस्ट के लिए संसाधनों को अलग-अलग रखने के लिए बड़ी समस्या हो सकती है. अपने-आप टेस्ट करने वाले फ़्रेमवर्क को किसी सर्वर को डीडीओएस नहीं करना चाहिए, क्योंकि कुछ टेस्ट उससे बात करते हैं.
मकसद
इस पेज का मकसद 'और' के लिए रनटाइम एनवायरमेंट को औपचारिक रूप से तय करना है बेज़ल टेस्ट का अनुमानित व्यवहार. यह टेस्ट पर भी ज़रूरी शर्तें लागू करेगा रनर और बिल्ड सिस्टम की सुविधा शामिल है.
टेस्ट एनवायरमेंट की खास जानकारी से, टेस्ट के लेखकों को ऐसे व्यवहार पर भरोसा करने से बचने में मदद मिलती है जिसकी जानकारी नहीं दी गई है. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने से जुड़े बदलाव करने में ज़्यादा आसानी होती है. इस स्पेसिफ़िकेशन में कुछ ऐसे गड़बड़ियों को ठीक किया गया है जिनकी वजह से, फ़िलहाल कई टेस्ट पास हो जाते हैं. हालांकि, ये टेस्ट पूरी तरह से हेर्मेटिक, डिटरमिनिस्टिक, और रीएंट्रेंट नहीं होते.
इस पेज का मकसद, नियमों के बारे में बताना और आधिकारिक जानकारी देना है. अगर यह स्पेसिफ़िकेशन और टेस्ट रनर के लागू किए गए व्यवहार से सहमत नहीं हैं, स्पेसिफ़िकेशन को प्राथमिकता दी जाती है.
प्रस्तावित स्पेसिफ़िकेशन
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" कीवर्ड का मतलब, IETF RFC 2119 में बताए गए मुताबिक है.
जांच का मकसद
Bazel टेस्ट का मकसद, रिपॉज़िटरी में चेक की गई सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है. (इस पेज पर, "सोर्स फ़ाइलों" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी गई कोई भी अन्य चीज़ शामिल होती है.) एक उपयोगकर्ता ने लिखा का इस्तेमाल करके, एक ऐसे इन्वैरिएंट पर दावा कर सकते हैं जिसे वे बनाए रखने की उम्मीद करते हैं. अन्य उपयोगकर्ता, बाद में टेस्ट चलाकर यह जांच करते हैं कि इनवैरिएंट का उल्लंघन हुआ है या नहीं. अगर परीक्षण, स्रोत फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी भी अन्य वैरिएबल पर निर्भर करता है, इसका मान कम हो जाता है, क्योंकि बाद में उपयोगकर्ता यह पक्का नहीं कर सकते कि उनके बदलाव गलत हैं जब टेस्ट पास होना बंद हो जाए.
इसलिए, जांच का नतीजा सिर्फ़ इन बातों पर निर्भर होना चाहिए:
- ऐसी सोर्स फ़ाइलें जिन पर टेस्ट की डिपेंडेंसी है
- बिल्ड सिस्टम के ऐसे प्रॉडक्ट जिन पर टेस्ट की डिपेंडेंसी है
- ऐसे संसाधन जिनके व्यवहार में कोई बदलाव नहीं होता. इसकी गारंटी, टेस्ट रनर देता है
फ़िलहाल, इस तरह की कार्रवाई को लागू नहीं किया गया है. हालांकि, टेस्ट रन करने वाले लोगों के पास, आने वाले समय में इस तरह की नीति को लागू करने का अधिकार सुरक्षित है.
बिल्ड सिस्टम की भूमिका
जांच के नियम, बाइनरी नियमों से मिलते-जुलते होते हैं. इनमें से हर नियम से एक ऐसा प्रोग्राम बनना चाहिए जिसे चलाया जा सके. कुछ भाषाओं के लिए, यह एक ऐसा स्टब प्रोग्राम है, जो परीक्षण कोड के साथ भाषा-विशिष्ट हार्नेस. जांच के नियमों को अन्य आउटपुट भी. टेस्ट रनर को मुख्य टेस्ट एक्सीक्यूटेबल के अलावा, रनफ़ाइल का मेनिफ़ेस्ट भी चाहिए. ये इनपुट फ़ाइलें होती हैं, जिन्हें रनटाइम के दौरान टेस्ट के लिए उपलब्ध कराया जाना चाहिए. साथ ही, टेस्ट के टाइप, साइज़, और टैग की जानकारी भी ज़रूरी हो सकती है.
बिल्ड सिस्टम, कोड के साथ-साथ डेटा डिलीवर करने के लिए, रनफ़ाइलों का इस्तेमाल कर सकता है. (यह को शेयर करके, हर टेस्ट बाइनरी को छोटा बनाने के लिए, ऑप्टिमाइज़ेशन के तौर पर इस्तेमाल किया जा सकता है जैसे, डाइनैमिक लिंकिंग का इस्तेमाल करके, अलग-अलग तरह की फ़ाइलें शामिल की जा सकती हैं.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई एक्सीक्यूटेबल, सोर्स या आउटपुट ट्री में ऐब्सलूट जगहों के लिए हार्डकोड किए गए रेफ़रंस के बजाय, टेस्ट रनर की दी गई runfiles इमेज के ज़रिए इन फ़ाइलों को लोड करे.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक प्रोग्राम होता है जिसे execve() के साथ शुरू किया जा सकता है. टेस्ट करने के अन्य तरीके भी हो सकते हैं; उदाहरण के लिए,
एक IDE, प्रोसेस में Java की जांच करने की अनुमति दे सकता है. हालांकि, टेस्ट को स्टैंडअलोन प्रोसेस के तौर पर चलाने के नतीजे को आधिकारिक माना जाना चाहिए. अगर जांच की प्रोसेस पूरी हो जाती है और सामान्य तौर पर, 'बाहर निकलने का कोड' शून्य पर सेट हो जाता है, तो इसका मतलब है कि जांच पूरी हो गई है. किसी भी अन्य नतीजे को जांच में गड़बड़ी माना जाता है. खास तौर पर, स्टैंडर्ड आउटपुट में PASS या FAIL में से किसी भी स्ट्रिंग को लिखने से, टेस्ट रनर पर कोई असर नहीं पड़ता.
अगर किसी जांच को लागू होने में ज़्यादा समय लगता है, तो वह कुछ संसाधनों की सीमा पार कर जाता है या जांच करता है अगर किसी अन्य कैटगरी में, रनर को ऐसी गतिविधियों का पता चलता है जिन पर पाबंदी है, तो वह टेस्ट को मारना चुन सकता है और उसे चलाने में नाकाम रहे. रनर को टेस्ट पास होने के बाद की रिपोर्ट नहीं करनी चाहिए टेस्ट प्रोसेस या किसी बच्चे को सिग्नल भेजकर.
पूरे टेस्ट टारगेट (अलग-अलग तरीकों या टेस्ट के लिए नहीं) को पूरा होने में लगने वाले समय की सीमा तय की जाती है. किसी टेस्ट की समयसीमा, इस टेबल के मुताबिक, उसके timeout एट्रिब्यूट पर आधारित होती है:
| टाइम आउट | समयसीमा (सेकंड) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| अनंत | 3600 |
जिन टेस्ट में टाइम आउट की साफ़ तौर पर जानकारी नहीं दी जाती है उनमें इस आधार पर अनुमान लगाया जाता है कि
टेस्ट की size को इस तरह से सेट अप करें:
| साइज़ | शामिल समय खत्म होने का लेबल |
|---|---|
| छोटा | छोटा |
| मध्यम | मध्यम |
| बड़ा | लंबा |
| बहुत बड़ा | अनंत |
किसी "बड़े" टेस्ट के लिए, टाइम आउट की कोई सेटिंग तय न करने पर, उसे 900 सेकंड तक चलने की अनुमति दी जाएगी. "कम" टाइम आउट वाले "मीडियम" टेस्ट को 60 सेकंड दिए जाएंगे.
timeout के उलट, size इसके इस्तेमाल की अनुमानित दर का पता लगाता है
स्थानीय तौर पर टेस्ट करते समय अन्य संसाधन (जैसे कि रैम), जैसा कि यहां बताया गया है
सामान्य परिभाषाएं.
size और timeout लेबल के सभी कॉम्बिनेशन कानूनी होते हैं, इसलिए "बहुत ज़्यादा" टेस्ट
तय किया जा सकता है कि "short" वाला टाइम आउट हो. लगता है कि उस पर
और जल्दी ऐक्सेस करने में मदद मिलती है.
टाइम आउट के बावजूद, टेस्ट जल्दी-जल्दी नतीजे दिखा सकते हैं. टेस्ट पर कोई कार्रवाई नहीं की जाएगी बहुत ज़्यादा टाइम आउट होने पर, भले ही एक चेतावनी जारी की जाए: आपको आम तौर पर, इस टाइम आउट को जितना हो सके उतना सटीक सेट करें. इससे कोई गड़बड़ी नहीं होगी.
जांच के टाइम आउट को --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 को
परीक्षण शार्डिंग सक्षम करें. जब sharding की सुविधा चालू होती है, तो हर स्hard के लिए एक बार टेस्ट रनर लॉन्च किया जाता है. एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS, शार्ड की संख्या है और TEST_SHARD_INDEX, शार्ड इंडेक्स है, जो 0 से शुरू होता है. रनर इस जानकारी का इस्तेमाल, यह चुनने के लिए करते हैं कि कौनसे टेस्ट
चलाने के लिए - उदाहरण के लिए, राउंड-रॉबिन रणनीति का इस्तेमाल करना. सभी टेस्ट रनर, टास्क को अलग-अलग हिस्सों में बांटने की सुविधा के साथ काम नहीं करते. अगर कोई रनर, शर्डिंग की सुविधा देता है, तो उसे TEST_SHARD_STATUS_FILE से तय की गई फ़ाइल की पिछली बार बदलाव करने की तारीख को बनाना या अपडेट करना होगा. नहीं तो, अगर
--incompatible_check_sharding_support
चालू है, तो Basel के शार्ड किए जाने पर वह टेस्ट में फ़ेल हो जाएगा.
शुरुआती शर्तें
टेस्ट को एक्ज़ीक्यूट करते समय, टेस्ट रनर को एक तय वैल्यू देनी होगी शर्तें.
टेस्ट रनर को हर टेस्ट को, एक्ज़ीक्यूटेबल टेस्ट के पाथ के साथ शुरू करना होगा
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 |
लिखने लायक डायरेक्ट्री में निजी फ़ाइल का ऐब्सलूट पाथ (लिखने के लिए इस्तेमाल किया जाता है) Logsplerator प्रोटोबफ़र लॉग) | ज़रूरी नहीं |
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_DIR डायरेक्ट्री को ज़िप कर दिया जाएगा और
के तहत एक outputs.zip फ़ाइल में जोड़ा गया
bazel-testlogs. |
ज़रूरी नहीं |
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 |
कम से कम 1024 |
RLIMIT_NPROC |
अनिर्दिष्ट |
RLIMIT_RSS |
अनलिमिटेड |
RLIMIT_RTPRIO |
अनिर्दिष्ट |
RLIMIT_SIGPENDING |
अनिर्दिष्ट |
RLIMIT_STACK |
अनलिमिटेड, या 2044 केबी <= rlim <= 8192 केबी |
शुरुआती प्रोसेस में लगने वाला समय (जैसा कि times() में बताया गया है) और संसाधन का इस्तेमाल
(जैसा कि getrusage() ने लौटाया है) की जानकारी नहीं दी गई है.
शेड्यूल करने की शुरुआती नीति और प्राथमिकता की जानकारी नहीं दी गई है.
होस्ट सिस्टम की भूमिका
टेस्ट के प्रत्यक्ष नियंत्रण में उपयोगकर्ता संदर्भ के पहलुओं के अलावा रनर, वह ऑपरेटिंग सिस्टम है जिस पर टेस्ट एक्ज़ीक्यूट किए जाते हैं इस्तेमाल की जा सकने वाली प्रॉपर्टी.
फ़ाइल सिस्टम
जांच के दौरान मिली रूट डायरेक्ट्री, असल रूट डायरेक्ट्री हो सकती है या नहीं.
/proc को माउंट किया जाएगा.
सभी बिल्ड टूल /usr में ऐब्सलूट पाथ पर मौजूद होंगे. इसका इस्तेमाल करने पर
स्थानीय इंस्टॉलेशन.
ऐसा हो सकता है कि /home से शुरू होने वाले पाथ उपलब्ध न हों. टेस्ट में किसी भी यूआरएल का ऐक्सेस नहीं होना चाहिए
चाहते हैं.
/tmp में लिखा जा सकता है, लेकिन टेस्ट में इन पाथ का इस्तेमाल नहीं किया जाना चाहिए.
टेस्ट में यह नहीं माना जाना चाहिए कि उनके खास पाथ के लिए कोई कॉन्सटैंट पाथ उपलब्ध है इस्तेमाल करें.
टेस्ट में यह नहीं माना जाना चाहिए कि माउंट किए गए किसी भी फ़ाइल सिस्टम के लिए, atimes चालू हैं.
उपयोगकर्ता और समूह
उपयोगकर्ता root, nobody, और unittest मौजूद होने चाहिए. ग्रुप रूट, कोई भी नहीं, और eng मौजूद होना चाहिए.
जांच, नॉन-रूट उपयोगकर्ता के तौर पर की जानी चाहिए. असल और असरदार यूज़र आईडी एक जैसे होने चाहिए. ग्रुप आईडी के लिए भी यही बात लागू होती है. इसके अलावा, मौजूदा उपयोगकर्ता आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप का नाम नहीं बताया गया है. पूरक समूह आईडी का सेट यह है अनिर्दिष्ट.
मौजूदा यूज़र आईडी और ग्रुप आईडी के नाम एक-दूसरे से जुड़े होने चाहिए. ये नाम ऐसे होने चाहिए:
getpwuid() और getgrgid() के साथ मिला. यह भी हो सकता है कि
पूरक ग्रुप आईडी.
मौजूदा उपयोगकर्ता के पास एक होम डायरेक्ट्री होनी चाहिए. हो सकता है कि उसमें बदलाव न किया जा सके. जांच के लिए ज़रूरी है उसे लिखने का प्रयास नहीं करना चाहिए.
नेटवर्किंग
होस्टनेम नहीं दिया गया है. इसमें एक बिंदु हो भी सकता है और नहीं भी. समस्या के समाधान के लिए, होस्टनेम को मौजूदा होस्ट का आईपी पता देना होगा. होस्टनेम कट को ठीक करना के बाद, पहला बिंदु भी काम करना चाहिए. होस्टनेम लोकल होस्ट का समाधान हो जाना चाहिए.
अन्य संसाधन
जांचों को कम से कम एक सीपीयू कोर की अनुमति दी गई है. अन्य साइटें उपलब्ध हो सकती हैं, लेकिन यह नहीं है गारंटी के साथ. इस कोर की परफ़ॉर्मेंस से जुड़े दूसरे पहलुओं के बारे में नहीं बताया गया है. किसी टेस्ट नियम में "cpu:n" टैग (जहां n कोई धनात्मक संख्या है) जोड़कर, सीपीयू कोर की संख्या को ज़्यादा किया जा सकता है. अगर किसी मशीन में सीपीयू की क्षमता का अनुरोध किया गया है, लेकिन इससे ज़्यादा कोर की ज़रूरत नहीं होती है. इसके बाद भी बैकेल की जांच की जाएगी. अगर टेस्ट में शर्डिंग, हर एक शार्ड सीपीयू (CPU) की संख्या सुरक्षित रखता है कोर यहां दिए गए हैं.
टेस्ट में सबप्रोसेस बनाई जा सकती हैं, लेकिन ग्रुप या सेशन को प्रोसेस नहीं किया जा सकता.
किसी टेस्ट में, इनपुट फ़ाइलों की संख्या सीमित होनी चाहिए. यह सीमा है इनमें बदलाव हो सकता है, लेकिन फ़िलहाल यह हज़ारों इनपुट की रेंज में है.
समय और तारीख
मौजूदा समय और तारीख नहीं दी गई है. सिस्टम के टाइमज़ोन की जानकारी नहीं दी गई है.
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
या TempDir जाएँ,
साथ ही, /tmp के तहत अस्थायी डायरेक्ट्री बनाने का अपना अलग तरीका है. जांच के इन फ़्रेमवर्क में ऐसी सुविधाएं शामिल होती हैं जो /tmp में मौजूद फ़ाइलों को हटा देती हैं. इसलिए, इनका इस्तेमाल तब भी किया जा सकता है, जब वे TEST_TMPDIR से बाहर फ़ाइलें बनाते हों.
टेस्ट को रनफ़ाइल मेकेनिज्म या रनटाइम एनवायरमेंट के उन हिस्सों के ज़रिए इनपुट ऐक्सेस करने चाहिए जिनका मकसद खास तौर पर इनपुट फ़ाइलें उपलब्ध कराना है.
टेस्ट को, अपने एक्सीक्यूटेबल की जगह से अनुमानित पाथ पर, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं करना चाहिए.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिम्बॉलिक है या नहीं
लिंक या उनका मिला-जुला रूप देखते हैं. रनफ़ाइल्स ट्री में डायरेक्ट्री के लिए सिमलंक हो सकते हैं.
टेस्ट में, रनफ़ाइल ट्री में .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए.
रनफ़ाइल ट्री में कोई डायरेक्ट्री, फ़ाइल या सिमलिंक नहीं होता (इसमें वे पाथ भी शामिल हैं जिनमें
ट्रैवर्स सिमलिंक) लिखने योग्य होना चाहिए. (इसका मतलब है कि शुरुआती वर्किंग डायरेक्ट्री में लिखने की अनुमति नहीं होनी चाहिए.) जांच में यह नहीं माना जाना चाहिए कि
रनफ़ाइल लिखने लायक है या उसका मालिकाना हक मौजूदा उपयोगकर्ता के पास है (उदाहरण के लिए, chmod और chgrp
विफल).
रनफ़ाइल ट्री (इसमें सिमलिंक ट्रैवर्स करने वाले पाथ भी शामिल हैं) नहीं बदलने चाहिए जांच के दौरान. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में ऐसा कोई बदलाव नहीं होना चाहिए जिससे runfiles ट्री में किसी पाथ को हल करने के नतीजे पर असर पड़े.
रिलीज़ से पहले बाहर निकलने के लिए, टेस्ट नीचे बताए गए पाथ पर एक फ़ाइल बना सकता है
शुरू करने पर TEST_PREMATURE_EXIT_FILE और बाहर निकलने पर उसे हटाएं. अगर बेज़ल
फ़ाइल होने पर, यह मान लिया जाएगा कि परीक्षण समय से पहले बाहर हो गया है और
'हो गया' के तौर पर मार्क करें.
टैग के लिए नाम तय करने के तरीके
टेस्ट के नियमों में कुछ टैग का खास मतलब होता है. यह भी देखें
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() नियम या उसके किसी भी कंपाइल-टाइम या रन-टाइम डिपेंडेंसी पर असर डालती हैं. सोर्स फ़ाइलों में बदलाव करने से, रनफ़ाइल डायरेक्ट्री के स्ट्रक्चर पर कोई असर नहीं पड़ता. इसलिए, रीबिल्ड करने की प्रोसेस शुरू नहीं होती.
कॉन्टेंट
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल हैं:
- रन-टाइम डिपेंडेंसी के लिए सिमलिंक: हर एक OutputFile और CommandRule ऐप्लिकेशन का इस्तेमाल करें जो
*_binary()नियम की रनटाइम डिपेंडेंसी है रनफ़ाइल डायरेक्ट्री में सिमलिंक होता है. सिमलिंक का नाम है$(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. सिंबल लिंक का टारगेट, रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सबप्रोग्राम एक समान रनफ़ाइल शेयर करते हैं डायरेक्ट्री.