टेस्ट करने की प्रोसेस के एनवायरमेंट के बारे में पूरी जानकारी.
बैकग्राउंड
बेज़ल बिल्ड भाषा में ऐसे नियम शामिल हैं जिनका इस्तेमाल करके अपने-आप कई भाषाओं में उपलब्ध हैं.
जांच, bazel test का इस्तेमाल करके की जाती हैं.
उपयोगकर्ता, टेस्ट बाइनरी भी सीधे एक्ज़ीक्यूट कर सकते हैं. इसकी अनुमति है, लेकिन इसका प्रमोशन नहीं किया जाता, मीटिंग शुरू करने से नीचे दिए गए मैंडेट का पालन नहीं होगा.
टेस्ट हर्मेटिक होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ उन संसाधनों का ऐक्सेस होना चाहिए तय की गई डिपेंडेंसी है. अगर परीक्षण सही तरीके से हर्मेटिक नहीं हों तो वे ऐतिहासिक तौर पर फिर से जनरेट किए जा सकने वाले नतीजे नहीं देते. यह काम किया जा सकता है: अपराधी को खोजने में कोई बड़ी समस्या हुई (यह तय करना कि किस बदलाव की वजह से टेस्ट खराब हुआ), इंजीनियरिंग से ऑडिट किए जाने की क्षमता और टेस्ट के रिसोर्स आइसोलेशन को रिलीज़ करना (ऑटोमेटेड टेस्टिंग फ़्रेमवर्क के लिए DDOS सर्वर नहीं बनाना चाहिए, क्योंकि कुछ टेस्ट यह).
मकसद
इस पेज का मकसद 'और' के लिए रनटाइम एनवायरमेंट को औपचारिक रूप से तय करना है बेज़ल टेस्ट का अनुमानित व्यवहार. यह टेस्ट पर भी ज़रूरी शर्तें लागू करेगा रनर और बिल्ड सिस्टम की ज़रूरत होती है.
टेस्ट एनवायरमेंट स्पेसिफ़िकेशन की मदद से, टेस्ट लेखकों पर भरोसा करने से बचा जा सकता है अनिर्दिष्ट व्यवहार करता है और इसलिए टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने के तरीके में बदलाव करें. स्पेसिफ़िकेशन, इन छेदों को कसते हैं मौजूदा समय में कई टेस्ट पास हो सकते हैं, भले ही वह हरमेटिक (हरमेटिक) न हो, सारणिक और फिर से जुड़ने का अधिकार है.
इस पेज का मकसद, प्रामाणिक और प्रामाणिक, दोनों तरह का कॉन्टेंट बनाना है. अगर यह स्पेसिफ़िकेशन और टेस्ट रनर के लागू किए गए व्यवहार से सहमत नहीं हैं, स्पेसिफ़िकेशन को प्राथमिकता दी जाती है.
प्रस्तावित विवरण
जैसे कि "ज़रूरी है", "नहीं करना चाहिए", "ज़रूरी", "करना चाहिए", "नहीं होना चाहिए", "चाहिए", "नहीं होना चाहिए", "सुझाया गया", "मई", और "ज़रूरी नहीं" जिन्हें ऐसे समझा जा सकता है आईईटीएफ़ आरएफ़सी 2119 में बताया गया है.
जांच का मकसद
Basel टेस्ट का मकसद सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है ने रिपॉज़िटरी में चेक किया. (इस पेज पर, "सोर्स फ़ाइलों" में टेस्ट डेटा, गोल्डन आउटपुट, और ऐसी अन्य चीज़ें जो वर्शन कंट्रोल में रखी जाती हैं.) एक उपयोगकर्ता ने लिखा का इस्तेमाल करके, एक ऐसे इन्वैरिएंट पर दावा कर सकते हैं जिसे वे बनाए रखने की उम्मीद करते हैं. अन्य उपयोगकर्ता बाद में टेस्ट करके यह पता लगाया जा सकता है कि इन्वैरिएंट टूट गया है या नहीं. अगर परीक्षण स्रोत फ़ाइलों (नॉन-हर्मेटिक) के अलावा किसी भी अन्य वैरिएबल पर निर्भर करता है, इसका मान कम हो जाता है, क्योंकि बाद में उपयोगकर्ता यह पक्का नहीं कर सकते कि उनके बदलाव गलत हैं जब टेस्ट पास होना बंद हो जाए.
इसलिए, जांच का नतीजा सिर्फ़ इन बातों पर निर्भर होना चाहिए:
- ऐसी सोर्स फ़ाइलें जिन पर टेस्ट की डिपेंडेंसी है
- बिल्ड सिस्टम के ऐसे प्रॉडक्ट जिन पर टेस्ट की डिपेंडेंसी है
- ऐसे संसाधन जिनका व्यवहार एक जैसा ही बना रहता है, जिसकी जांच टेस्ट रनर ने की हो
फ़िलहाल, इस तरह की कार्रवाई को लागू नहीं किया गया है. हालांकि, जांच करने वाले लोग का अधिकार है.
बिल्ड सिस्टम की भूमिका
जांच के नियम बाइनरी नियमों के समान हैं, क्योंकि हर नियम पर एक एक्ज़ीक्यूटेबल नियम लागू होना चाहिए कार्यक्रम. कुछ भाषाओं के लिए, यह एक ऐसा स्टब प्रोग्राम है, जो परीक्षण कोड के साथ भाषा-विशिष्ट हार्नेस. जांच के नियमों को अन्य आउटपुट भी. प्राइमरी टेस्ट के एक्ज़ीक्यूटेबल के अलावा, टेस्ट रनर runfiles के मेनिफ़ेस्ट की ज़रूरत होगी. यह ऐसी इनपुट फ़ाइलें हैं जिन्हें उपलब्ध कराया जाना चाहिए टेस्ट करने के लिए इस्तेमाल किया जा सकता है. साथ ही, इसके लिए टाइप, साइज़, और एक टेस्ट के टैग.
बिल्ड सिस्टम कोड और डेटा डिलीवर करने के लिए रनफ़ाइल का इस्तेमाल कर सकता है. (यह को शेयर करके, हर टेस्ट बाइनरी को छोटा बनाने के लिए, ऑप्टिमाइज़ेशन के तौर पर इस्तेमाल किया जा सकता है जैसे, डाइनैमिक लिंकिंग का इस्तेमाल करके, कई तरह की फ़ाइलें शामिल की जा सकती हैं.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट की गई एक्ज़ीक्यूटेबल फ़ाइल, रनफ़ाइल के ज़रिए इन फ़ाइलों को लोड करे ऐब्सलूट रेफ़रंस के बजाय, हार्डकोड किए गए रेफ़रंस के बजाय, टेस्ट रनर से मिली इमेज सोर्स या आउटपुट ट्री में जगहें.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक ऐसा प्रोग्राम है जिसे
execve() के साथ शुरू किया गया. टेस्ट करने के अन्य तरीके भी हो सकते हैं; उदाहरण के लिए,
एक IDE, प्रोसेस में Java की जांच करने की अनुमति दे सकता है. हालांकि, नतीजा
एक स्टैंडअलोन प्रोसेस के तौर पर टेस्ट करने के लिए, इसे आधिकारिक माना जाना चाहिए. अगर आपने
एक परीक्षण प्रक्रिया पूरी होती है और सामान्यत:
शून्य, परीक्षण पास हो गया है. किसी भी अन्य नतीजे को टेस्ट फ़ेल माना जाता है. तय सीमा में
खास तौर पर, stdout पर किसी भी PASS या FAIL स्ट्रिंग को लिखने से
और टेस्ट रनर के लिए महत्व के बारे में बताता है.
अगर किसी जांच को लागू होने में ज़्यादा समय लगता है, तो वह कुछ संसाधनों की सीमा पार कर जाता है या जांच करता है अगर रनर को किसी ऐसी गतिविधि का पता चलता है जिस पर पाबंदी है, तो वह टेस्ट को नुकसान पहुंचाने का विकल्प चुन सकता है और उसे चलाने में नाकाम रहे. रनर को टेस्ट पास होने के बाद की रिपोर्ट नहीं करनी चाहिए टेस्ट प्रोसेस या किसी बच्चे को सिग्नल भेजकर.
पूरे टेस्ट टारगेट को (अलग-अलग तरीकों या टेस्ट के लिए नहीं) को सीमित
पूरा होने तक चलने में लगने वाला समय. टेस्ट की समयसीमा,
timeout एट्रिब्यूट
जोड़ें:
| टाइम आउट | समयसीमा (सेकंड) |
|---|---|
| छोटा | 60 |
| मध्यम | 300 |
| लंबा | 900 |
| इटरनल | 3600 |
जिन टेस्ट में टाइम आउट की जानकारी साफ़ तौर पर नहीं दी जाती है उनमें इस आधार पर अनुमान लगाया जाता है कि
टेस्ट की size को इस तरह से सेट अप करें:
| साइज़ | शामिल समय खत्म होने का लेबल |
|---|---|
| छोटा | छोटा |
| मध्यम | मध्यम |
| बड़ा | लंबा |
| बहुत बड़ा | इटरनल |
एक "बड़ा" बिना किसी तय टाइम आउट सेटिंग के टेस्ट के लिए, 900 कोड असाइन किए जाएंगे सेकंड में चलने के लिए. एक "मीडियम" "short" वाले टाइम आउट के साथ टेस्ट करें 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
टेस्ट शार्डिंग. शार्डिंग की सुविधा चालू होने पर, टेस्ट रनर को एक बार लॉन्च किया जाता है
शार्ड. एनवायरमेंट वैरिएबल TEST_TOTAL_SHARDS यह है
शार्ड की संख्या और TEST_SHARD_INDEX शार्ड है
इंडेक्स, 0 से शुरू. रनर इस जानकारी का इस्तेमाल यह चुनने के लिए करते हैं कि कौनसे टेस्ट
रन - उदाहरण के लिए, राउंड-रॉबिन रणनीति का इस्तेमाल करके. जांच करने वाले सभी लोगों के लिए यह सुविधा उपलब्ध नहीं है
शार्डिंग. अगर कोई रनर शार्डिंग की सुविधा देता है, तो उसे
फ़ाइल की संशोधित तारीख द्वारा निर्दिष्ट की गई फ़ाइल
TEST_SHARD_STATUS_FILE. अगर ऐसा नहीं होता है, तो बेज़ल इसे मान लेते हैं
शार्डिंग की सुविधा काम नहीं करती और अतिरिक्त रनर लॉन्च नहीं करती.
शुरुआती शर्तें
टेस्ट को एक्ज़ीक्यूट करते समय, टेस्ट रनर को एक तय वैल्यू देनी होगी शर्तें.
टेस्ट रनर को हर टेस्ट को, एक्ज़ीक्यूटेबल टेस्ट के पाथ के साथ शुरू करना होगा
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 |
लिखने लायक डायरेक्ट्री में निजी फ़ाइल का ऐब्सलूट पाथ (लिखने के लिए इस्तेमाल किया जाता है) 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 |
रनफ़ाइल ट्री के बेस का ऐब्सलूट पाथ | ज़रूरी है |
TEST_TOTAL_SHARDS |
कुल
shard count
अगर sharding का इस्तेमाल किया जाता है |
ज़रूरी नहीं |
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 |
वह जगह जहां जांच कार्रवाइयों के लिए, जांच के नतीजे की एक्सएमएल आउटपुट फ़ाइल लिखी जानी चाहिए. ऐसा न होने पर, Basel, टेस्ट लॉग को रैप करके एक डिफ़ॉल्ट एक्सएमएल आउटपुट फ़ाइल जनरेट करता है का इस्तेमाल किया जा सकता है. एक्सएमएल स्कीमा 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 चालू हैं.
उपयोगकर्ता और समूह
यूज़र्स रूट, कोई भी नहीं, और यूनिटटेस्ट मौजूद होना चाहिए. ग्रुप रूट, कोई भी नहीं, और eng मौजूद होना चाहिए.
जांच, नॉन-रूट उपयोगकर्ता के तौर पर की जानी चाहिए. वास्तविक और प्रभावी उपयोगकर्ता आईडी को बराबर होना चाहिए; इसी तरह समूह आईडी के लिए. इसके अलावा, मौजूदा यूज़र आईडी, ग्रुप आईडी, उपयोगकर्ता नाम और ग्रुप का नाम साफ़ तौर पर न बताया गया हो. पूरक समूह आईडी का सेट यह है अनिर्दिष्ट.
मौजूदा यूज़र आईडी और ग्रुप आईडी के नाम एक-दूसरे से जुड़े होने चाहिए. ये नाम ऐसे होने चाहिए:
getpwuid() और getgrgid() के साथ मिला. यह भी हो सकता है कि
पूरक ग्रुप आईडी.
मौजूदा उपयोगकर्ता के पास एक होम डायरेक्ट्री होनी चाहिए. ऐसा हो सकता है कि यह लिखा न जा सके. जांच के लिए ज़रूरी है उसे लिखने का प्रयास नहीं करना चाहिए.
नेटवर्किंग
होस्टनेम की जानकारी नहीं है. इसमें एक बिंदु हो भी सकता है और नहीं भी. समस्या के समाधान के लिए, होस्टनेम को मौजूदा होस्ट का आईपी पता देना होगा. होस्टनेम कट को ठीक करना के बाद, पहला बिंदु भी काम करना चाहिए. होस्टनेम लोकल होस्ट का समाधान हो जाना चाहिए.
अन्य संसाधन
जांचों को कम से कम एक सीपीयू कोर की अनुमति दी गई है. अन्य साइटें उपलब्ध हो सकती हैं, लेकिन यह नहीं है गारंटी के साथ. इस कोर की परफ़ॉर्मेंस से जुड़े दूसरे पहलुओं के बारे में नहीं बताया गया है. आप टैग जोड़कर, सीपीयू कोर की ज़्यादा संख्या का रिज़र्वेशन बढ़ाएं "cpu:n" (जहां n एक धनात्मक संख्या है) को किसी परीक्षण नियम में बदलें. अगर किसी मशीन में सीपीयू की क्षमता का अनुरोध किया गया है, लेकिन इससे ज़्यादा कोर की ज़रूरत नहीं होती है. इसके बाद भी बैकेल की जांच की जाएगी. अगर टेस्ट में शर्डिंग, हर एक शार्ड सीपीयू (CPU) की संख्या सुरक्षित रखता है कोर यहां दिए गए हैं.
टेस्ट में सबप्रोसेस बनाई जा सकती हैं, लेकिन ग्रुप या सेशन को प्रोसेस नहीं किया जा सकता.
टेस्ट में इस्तेमाल की जाने वाली इनपुट फ़ाइलों की संख्या सीमित होती है. यह सीमा है इनमें बदलाव हो सकता है, लेकिन फ़िलहाल यह हज़ारों इनपुट की रेंज में है.
समय और तारीख
मौजूदा समय और तारीख नहीं दी गई है. सिस्टम के टाइमज़ोन की जानकारी नहीं दी गई है.
X Windows उपलब्ध भी हो सकता है और नहीं भी. वे टेस्ट जिनके लिए X सर्वर की ज़रूरत है, वे शुरू होने चाहिए Xvfb.
फ़ाइल सिस्टम के साथ इंटरैक्शन की जांच करना
टेस्ट एनवायरमेंट वैरिएबल में बताए गए सभी फ़ाइल पाथ, जब तक अलग से न बताया गया हो.
जांचों में बताई गई डायरेक्ट्री में ही फ़ाइलें बनाई जानी चाहिए
$TEST_TMPDIR और $TEST_UNDECLARED_OUTPUTS_DIR (अगर सेट हो).
शुरुआत में ये डायरेक्ट्री खाली रहेंगी.
जांच में इन डायरेक्ट्री को हटाने, बदलने या इनमें बदलाव करने की कोशिश नहीं की जानी चाहिए.
ये डायरेक्ट्री, सिम्बॉलिक लिंक हो सकती हैं.
$TEST_TMPDIR/. का फ़ाइल सिस्टम टाइप तय नहीं किया गया है.
टेस्ट, फ़ाइलों के फ़ॉर्मैट में .part फ़ाइलें भी
जिन आउटपुट फ़ाइलों का एलान नहीं किया गया है उनके बारे में बताने के लिए, $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR.
बहुत कम मामलों में, टेस्ट के ज़रिए /tmp में फ़ाइलें बनानी पड़ सकती हैं. उदाहरण के लिए,
Unix डोमेन सॉकेट के लिए पाथ की लंबाई की सीमाएं
आम तौर पर, /tmp के तहत सॉकेट बनाना पड़ता है. बेज़ल ये काम नहीं कर पाएंगे
ऐसी फ़ाइलों को ट्रैक करना; अपने-आप में पूरा कंट्रोल होना चाहिए, ताकि टेस्ट हर्मेटिक हो.
दूसरे से टकराने से बचने के लिए पाथ, साथ-साथ टेस्ट और नॉन-टेस्ट चलाना
प्रोसेस को पूरा करने में मदद मिलती है और इसके ज़रिए /tmp में बनाई जाने वाली फ़ाइलों को हटाने का अनुरोध किया जाता है.
कुछ लोकप्रिय टेस्टिंग फ़्रेमवर्क, जैसे कि
JUnit4 TemporaryFolder
या TempDir जाएँ,
साथ ही, /tmp के तहत अस्थायी डायरेक्ट्री बनाने का अपना अलग तरीका है. ये टेस्टिंग
फ़्रेमवर्क में ऐसी सुविधा शामिल है जो /tmp में मौजूद फ़ाइलों को हटा देती है. इसलिए,
चाहे वे TEST_TMPDIR के बाहर फ़ाइलें बनाते हों.
टेस्ट में runfiles तरीके या इसके दूसरे हिस्सों के ज़रिए, इनपुट ऐक्सेस किए जाने चाहिए एक्ज़ीक्यूशन एनवायरमेंट, जो खास तौर पर इनपुट फ़ाइलें बनाने के लिए है उपलब्ध हैं.
टेस्ट में बताए गए पाथ के लिए, बिल्ड सिस्टम के अन्य आउटपुट को ऐक्सेस नहीं किया जाना चाहिए ऐक्सेस करने की अनुमति दे सकते हैं.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिम्बॉलिक है या नहीं
लिंक या उनका मिला-जुला रूप देखते हैं. रनफ़ाइल ट्री में डायरेक्ट्री के सिमलिंक हो सकते हैं.
जांच में रनफ़ाइल के अंदर .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए
पेड़
रनफ़ाइल ट्री में कोई डायरेक्ट्री, फ़ाइल या सिमलिंक नहीं होता (इसमें वे पाथ भी शामिल हैं जिनमें
ट्रैवर्स सिमलिंक) लिखने योग्य होना चाहिए. (यह कदम उठाने के साथ-साथ,
डायरेक्ट्री, लिखने लायक नहीं होनी चाहिए.) जांच में यह नहीं माना जाना चाहिए कि
रनफ़ाइल लिखने लायक है या उसका मालिकाना हक मौजूदा उपयोगकर्ता के पास है (उदाहरण के लिए, chmod और chgrp
विफल).
रनफ़ाइल ट्री (उन पाथ के साथ जो सिमलिंक को पार करते हैं) नहीं बदलना चाहिए जांच के दौरान. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम के माउंट में बदलाव नहीं किया जाना चाहिए किसी भी तरीके से हो, जिससे रनफ़ाइल में पाथ का समाधान करने के नतीजे पर असर पड़ता हो पेड़
रिलीज़ होने से पहले बाहर निकलने के लिए, टेस्ट नीचे बताए गए पाथ पर एक फ़ाइल बना सकता है
शुरू करने पर TEST_PREMATURE_EXIT_FILE और बाहर निकलने पर उसे हटाएं. अगर बेज़ल
फ़ाइल होने पर, यह मान लिया जाएगा कि परीक्षण समय से पहले बाहर हो गया है और
'हो गया' के तौर पर मार्क करें.
टैग कन्वेंशन
जांच के नियमों में कुछ टैग का एक खास मतलब होता है. यह भी देखें
tags एट्रिब्यूट पर बैजल बिल्ड एनसाइक्लोपीडिया.
| टैग | मतलब |
|---|---|
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() नियम. रनफ़ाइल डायरेक्ट्री, बिल्ड फ़ाइल के सेट पर निर्भर करती है
ऐसी फ़ाइलें जो *_binary() नियम या उसके किसी कंपाइल-टाइम या रन-टाइम पर असर डालती हैं
निर्भरता. स्रोत फ़ाइलों में बदलाव करने से
रनफ़ाइल डायरेक्ट्री होती है और इस वजह से कोई रीबिल्डिंग ट्रिगर नहीं होती.
कॉन्टेंट
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल हैं:
- रन-टाइम डिपेंडेंसी के लिए सिमलिंक: हर एक OutputFile और CommandRule ऐप्लिकेशन का इस्तेमाल करें जो
*_binary()नियम की रनटाइम डिपेंडेंसी है रनफ़ाइल डायरेक्ट्री में सिमलिंक होता है. सिमलिंक का नाम है$(WORKSPACE)/package_name/rule_name. उदाहरण के लिए, सर्वर के लिए सिमलिंक का नाम$(WORKSPACE)/deps/server/serverहोगा और पूरा पाथ होगा$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. सिमलिंक का डेस्टिनेशन, OutputFile का OutputFileName() है या CommandRule, जिसे ऐब्सलूट पाथ के तौर पर दिखाया जाता है. इसलिए, सिमलिंक$(WORKSPACE)/linux-dbg/deps/server/42/serverहो सकता है. - सब-रन फ़ाइलों के सिमलिंक: रन-टाइम वाले हर
*_binary()Z के लिए*_binary()C की डिपेंडेंसी, रनफ़ाइल में दूसरा लिंक है C की डायरेक्ट्री को Z की रनफ़ाइल पर ले जाएं. सिमलिंक का नाम है$(WORKSPACE)/package_name/rule_name.runfiles. सिमलिंक का टारगेट यह है रनफ़ाइल डायरेक्ट्री में उपलब्ध है. उदाहरण के लिए, सभी सबप्रोग्राम एक समान रनफ़ाइल शेयर करते हैं डायरेक्ट्री.