टेस्ट करने की प्रोसेस के एनवायरमेंट के बारे में पूरी जानकारी.
बैकग्राउंड
बेज़ल बिल्ड भाषा में ऐसे नियम होते हैं जिनका इस्तेमाल कई भाषाओं में अपने-आप होने वाले टेस्ट प्रोग्राम को तय करने के लिए किया जा सकता है.
जांच, bazel test का इस्तेमाल करके की जाती हैं.
उपयोगकर्ता, टेस्ट बाइनरी भी सीधे एक्ज़ीक्यूट कर सकते हैं. इसकी अनुमति है, लेकिन इसका प्रमोशन नहीं किया जाता. ऐसा इसलिए, क्योंकि इसे शुरू करने से नीचे दिए गए मैंडेट का पालन नहीं होगा.
टेस्ट हर्मेटिक होने चाहिए: इसका मतलब है कि उन्हें सिर्फ़ उन रिसॉर्स को ऐक्सेस करना चाहिए जिन पर उनकी डिपेंडेंसी का एलान किया गया है. अगर जांच सही तरीके से हर्मेटिक नहीं होती हैं, तो वे ऐसे नतीजे नहीं देती हैं जिन्हें पहले इस्तेमाल किया जा सकता था. यह गड़बड़ी ढूंढने की बड़ी समस्या (यह तय करना कि किस बदलाव ने टेस्ट में गड़बड़ी हुई), इंजीनियरिंग ऑडिटेबिलिटी, और टेस्ट के लिए रिसॉर्स आइसोलेशन (अपने-आप होने वाली टेस्टिंग फ़्रेमवर्क) के लिए एक बड़ी समस्या हो सकती है, क्योंकि कुछ टेस्ट में इसके बारे में जानकारी देने के लिए, डीडीओएस का सर्वर नहीं होता.
कैंपेन का मकसद
इस पेज का मकसद, बेज़ल टेस्ट के लिए रनटाइम एनवायरमेंट और उम्मीद के मुताबिक व्यवहार तैयार करना है. इससे टेस्ट रनर और बिल्ड सिस्टम पर भी ज़रूरी शर्तें लागू होंगी.
टेस्ट एनवायरमेंट के स्पेसिफ़िकेशन की मदद से, टेस्ट करने वाले लोग अनजान व्यवहार पर भरोसा करने से बच जाते हैं. इससे टेस्टिंग इन्फ़्रास्ट्रक्चर को लागू करने के तरीके में बदलाव करने की ज़्यादा आज़ादी मिलती है. यह स्पेसिफ़िकेशन कुछ ऐसे छेदों को मज़बूत करता है जो सही तरीके से हर्मेटिक, डिटरमिनिस्टिक, और रिएंट्रेंटर न होने के बावजूद भी कई टेस्ट को पास होने देते हैं.
इस पेज का मकसद, प्रामाणिक और प्रामाणिक, दोनों तरह का कॉन्टेंट बनाना है. अगर यह जानकारी और टेस्ट रनर के लागू किए गए व्यवहार में अंतर होता है, तो इस स्पेसिफ़िकेशन को प्राथमिकता दी जाती है.
प्रस्तावित विवरण
जैसे कि मुख्य शब्द "करना है", "नहीं करना", "ज़रूरी", "करना चाहिए", "नहीं करना चाहिए", "चाहिए", "नहीं करना चाहिए", "सुझाया गया", "शायद", और "ज़रूरी नहीं" का मतलब आईईटीएफ़ आरएफ़सी 2119 में बताया गया है.
जांच का मकसद
Basel टेस्ट का मकसद, रिपॉज़िटरी में चेक की गई सोर्स फ़ाइलों की कुछ प्रॉपर्टी की पुष्टि करना है. (इस पेज पर, "सोर्स फ़ाइलें" में टेस्ट डेटा, गोल्डन आउटपुट, और वर्शन कंट्रोल में रखी जाने वाली बाकी सभी चीज़ें शामिल होती हैं.) एक उपयोगकर्ता किसी ऐसे वैरिएंट पर दावा करने के लिए टेस्ट लिखता है जिसे वह बनाए रखना चाहता है. अन्य उपयोगकर्ता बाद में टेस्ट करके यह देखते हैं कि इन्वैरिएंट टूट गया है या नहीं. अगर टेस्ट, सोर्स फ़ाइलों के अलावा किसी भी वैरिएबल (नॉन-हर्मेटिक) पर निर्भर करता है, तो उसकी वैल्यू कम हो जाती है. इसकी वजह यह है कि बाद में उपयोगकर्ता यह पक्का नहीं कर पाते कि टेस्ट पास होना बंद होने पर, उनके किए गए बदलावों में कोई गलती है.
इसलिए, जांच का नतीजा सिर्फ़ इन बातों पर निर्भर होना चाहिए:
- ऐसी सोर्स फ़ाइलें जिन पर टेस्ट की डिपेंडेंसी है
- बिल्ड सिस्टम के ऐसे प्रॉडक्ट जिन पर टेस्ट की डिपेंडेंसी है
- ऐसे संसाधन जिनका व्यवहार एक जैसा ही बना रहता है, जिसकी जांच टेस्ट रनर ने की हो
फ़िलहाल, इस तरह की कार्रवाई को लागू नहीं किया गया है. हालांकि, जांच करने वाले लोगों के पास, आने वाले समय में इस तरह के नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को लागू करने का अधिकार सुरक्षित है.
बिल्ड सिस्टम की भूमिका
जांच के नियम बाइनरी नियमों के जैसे होते हैं. हर नियम पर एक्ज़ीक्यूटेबल प्रोग्राम होना चाहिए. कुछ भाषाओं के लिए, यह एक स्टब प्रोग्राम है. इसमें भाषा के हिसाब से टेस्ट कोड को एक साथ इस्तेमाल किया जाता है. जांच के नियमों से, दूसरे आउटपुट भी जनरेट होने चाहिए. प्राइमरी टेस्ट एक्ज़ीक्यूटेबल के अलावा, टेस्ट रनर को रनफ़ाइल और ऐसी इनपुट फ़ाइलों की ज़रूरत होगी जिन्हें रनटाइम के दौरान टेस्ट में उपलब्ध कराया जाना चाहिए. इसके साथ ही, उसे टेस्ट के टाइप, साइज़, और टैग के बारे में जानकारी की ज़रूरत पड़ सकती है.
बिल्ड सिस्टम कोड और डेटा डिलीवर करने के लिए रनफ़ाइल का इस्तेमाल कर सकता है. (इसका इस्तेमाल, डाइनैमिक लिंकिंग के ज़रिए जैसे सभी टेस्ट में फ़ाइलें शेयर करके, हर टेस्ट बाइनरी को छोटा करने के लिए ऑप्टिमाइज़ेशन के तौर पर किया जा सकता है.) बिल्ड सिस्टम को यह पक्का करना चाहिए कि जनरेट किया गया एक्ज़ीक्यूटेबल इमेज, इन फ़ाइलों को सोर्स या आउटपुट ट्री में पूरी जगहों के हार्डकोड किए गए रेफ़रंस के बजाय, टेस्ट रनर से मिली रनफ़ाइल इमेज के ज़रिए लोड करे.
टेस्ट रनर की भूमिका
टेस्ट रनर के हिसाब से, हर टेस्ट एक प्रोग्राम है जिसे
execve() से शुरू किया जा सकता है. टेस्ट लागू करने के दूसरे तरीके भी हो सकते हैं. उदाहरण के लिए,
आईडीई, Java की जांच को प्रोसेस में लागू करने की अनुमति दे सकता है. हालांकि, इस जांच को एक स्टैंडअलोन प्रोसेस के तौर पर
चलाने के नतीजे को आधिकारिक माना जाना चाहिए. अगर
कोई जांच पूरी होती है और एक एग्ज़िट कोड शून्य के साथ सामान्य रूप से खत्म हो जाती है, तो इसका मतलब है कि टेस्ट पास हो गया है. किसी भी अन्य नतीजे को टेस्ट फ़ेल माना जाता है. खास तौर पर, stdout पर 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" को सेट करें. बेज़ल --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
चालू है, तो शार्ड होने पर Basel टेस्ट को पूरा नहीं कर पाएगा.
शुरुआती शर्तें
टेस्ट करते समय, टेस्ट रनर को कुछ शुरुआती शर्तें तय करनी होती हैं.
टेस्ट रनर को 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 चालू हैं.
उपयोगकर्ता और समूह
यूज़र्स रूट, कोई भी नहीं, और यूनिटटेस्ट मौजूद होना चाहिए. ग्रुप रूट, कोई भी नहीं, और EN का मौजूद होना ज़रूरी है.
जांच, नॉन-रूट उपयोगकर्ता के तौर पर की जानी चाहिए. असली और असरदार उपयोगकर्ता आईडी एक जैसे होने चाहिए. इसी तरह ग्रुप आईडी के लिए भी ज़रूरी है. इसके अलावा, मौजूदा यूज़र आईडी, ग्रुप आईडी, उपयोगकर्ता का नाम, और ग्रुप का नाम नहीं बताया गया है. पूरक ग्रुप आईडी के सेट की जानकारी नहीं दी गई है.
मौजूदा यूज़र आईडी और ग्रुप आईडी में मिलते-जुलते नाम होने चाहिए, जिन्हें getpwuid() और getgrgid() की मदद से वापस पाया जा सके. ऐसा हो सकता है कि पूरक ग्रुप आईडी
के लिए भी ऐसा न हो.
मौजूदा उपयोगकर्ता के पास एक होम डायरेक्ट्री होनी चाहिए. ऐसा हो सकता है कि यह लिखा न जा सके. टेस्ट में इसके साथ लिखने की कोशिश नहीं की जानी चाहिए.
नेटवर्किंग
होस्टनेम की जानकारी नहीं है. इसमें एक बिंदु हो भी सकता है और नहीं भी. होस्टनेम को हल करने के लिए, आपको मौजूदा होस्ट का आईपी पता देना होगा. पहले बिंदु के बाद, होस्टनेम कट करने की समस्या को हल करना भी ज़रूरी है. होस्टनेम लोकल होस्ट का समाधान हो जाना चाहिए.
अन्य संसाधन
जांचों को कम से कम एक सीपीयू कोर की अनुमति दी गई है. अन्य उपलब्ध हो सकते हैं, लेकिन इसकी गारंटी नहीं है. इस कोर की परफ़ॉर्मेंस से जुड़े दूसरे पहलुओं के बारे में नहीं बताया गया है. जांच के नियम में "cpu:n" (जहां n एक पॉज़िटिव संख्या है) टैग जोड़कर, सीपीयू कोर की ज़्यादा संख्या तक रिज़र्वेशन को बढ़ाया जा सकता है. अगर किसी मशीन में अनुरोध किए गए सीपीयू की क्षमता से कम सीपीयू कोर हैं, तो भी Baज़र को टेस्ट चलेगा. अगर किसी टेस्ट में शार्डिंग का इस्तेमाल किया जाता है, तो हर शार्ड अपने हिसाब से सीपीयू कोर की संख्या को रिज़र्व रखेगा.
टेस्ट में सबप्रोसेस बनाई जा सकती हैं, लेकिन ग्रुप या सेशन को प्रोसेस नहीं किया जा सकता.
टेस्ट में इस्तेमाल की जाने वाली इनपुट फ़ाइलों की संख्या सीमित होती है. इस सीमा में बदलाव हो सकता है. हालांकि, फ़िलहाल यह संख्या हज़ारों इनपुट की रेंज में है.
समय और तारीख
मौजूदा समय और तारीख नहीं दी गई है. सिस्टम के टाइमज़ोन की जानकारी नहीं दी गई है.
X Windows उपलब्ध भी हो सकता है और नहीं भी. जिन टेस्ट के लिए X सर्वर की ज़रूरत होती है वे Xvfb से शुरू होने चाहिए.
फ़ाइल सिस्टम के साथ इंटरैक्शन की जांच करना
टेस्ट एनवायरमेंट वैरिएबल में दिए गए सभी फ़ाइल पाथ, लोकल फ़ाइल सिस्टम पर कहीं भी ले जाते हैं. ऐसा तब तक होता है, जब तक अलग से न बताया गया हो.
जांच करने पर, सिर्फ़ $TEST_TMPDIR और $TEST_UNDECLARED_OUTPUTS_DIR (अगर सेट हो) की बताई गई डायरेक्ट्री में फ़ाइलें बनाई जानी चाहिए.
शुरुआत में ये डायरेक्ट्री खाली रहेंगी.
जांच में इन डायरेक्ट्री को हटाने, बदलने या इनमें बदलाव करने की कोशिश नहीं की जानी चाहिए.
ये डायरेक्ट्री, सिम्बॉलिक लिंक हो सकती हैं.
$TEST_TMPDIR/. का फ़ाइल सिस्टम टाइप तय नहीं किया गया है.
अघोषित आउटपुट फ़ाइलों के बारे में जानकारी देने के लिए टेस्ट, $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR में .part फ़ाइलें भी लिख सकते हैं.
बहुत कम मामलों में, टेस्ट के ज़रिए /tmp में फ़ाइलें बनानी पड़ सकती हैं. उदाहरण के लिए,
Unix डोमेन सॉकेट के लिए पाथ की लंबाई की सीमा
आम तौर पर /tmp के तहत सॉकेट बनाना ज़रूरी होता है. बेज़ल ऐसी फ़ाइलों को ट्रैक नहीं कर पाएगा; टेस्ट को हर्मेटिक होने का ध्यान रखना चाहिए, ताकि अन्य पाथ का इस्तेमाल करने के साथ-साथ टेस्ट और बिना टेस्ट वाली प्रोसेस को चलाने से रोका जा सके. साथ ही, /tmp में बनाई जाने वाली फ़ाइलों को साफ़ किया जा सके.
JUnit4 TemporaryFolder
या Go TempDir जैसे कुछ लोकप्रिय टेस्टिंग फ़्रेमवर्क में, /tmp में अस्थायी डायरेक्ट्री बनाने के अलग-अलग तरीके होते हैं. इन टेस्टिंग फ़्रेमवर्क में ऐसी सुविधा शामिल है जो /tmp में मौजूद फ़ाइलों को मिटा देती है. इसलिए, TEST_TMPDIR के बाहर फ़ाइलें बनाते समय भी इनका इस्तेमाल किया जा सकता है.
टेस्ट को रनफ़ाइल तरीके से या एक्ज़ीक्यूशन एनवायरमेंट के दूसरे हिस्सों में इनपुट ऐक्सेस करना चाहिए. इन्हें खास तौर पर, इनपुट फ़ाइलों को उपलब्ध कराने के मकसद से ऐक्सेस किया जाता है.
टेस्ट में उन पाथ के बिल्ड सिस्टम के दूसरे आउटपुट को ऐक्सेस नहीं किया जाना चाहिए जिनका अनुमान खुद उनके एक्ज़ीक्यूटेबल की जगह से लगाया जाता है.
यह नहीं बताया गया है कि रनफ़ाइल ट्री में सामान्य फ़ाइलें, सिम्बॉलिक लिंक या मिक्सचर शामिल हैं या नहीं. रनफ़ाइल ट्री में डायरेक्ट्री के सिमलिंक हो सकते हैं.
टेस्ट में रनफ़ाइल ट्री के अंदर .. कॉम्पोनेंट वाले पाथ का इस्तेमाल नहीं किया जाना चाहिए.
रनफ़ाइल ट्री के अंदर किसी भी डायरेक्ट्री, फ़ाइल या सिमलिंक को लिखने की ज़रूरत नहीं है. इसमें वे पाथ भी शामिल हैं जो सिमलिंक
को ट्रैक करते हैं. (इसका मतलब है कि शुरुआती काम करने वाली डायरेक्ट्री
लिखने लायक नहीं होनी चाहिए.) जांच में यह नहीं मानना चाहिए कि रनफ़ाइल का कोई भी हिस्सा लिखने लायक है या उसका मालिकाना हक मौजूदा उपयोगकर्ता के पास है (उदाहरण के लिए, chmod और chgrp काम नहीं कर सकते).
जांच के दौरान रनफ़ाइल ट्री (जिसमें सिमलिंक ट्रैवर्स करने वाले पाथ शामिल हैं) नहीं बदलना चाहिए. पैरंट डायरेक्ट्री और फ़ाइल सिस्टम माउंट में ऐसा कोई बदलाव नहीं होना चाहिए जिससे रनफ़ाइल ट्री में पाथ के काम करने के नतीजे पर असर पड़ता हो.
रिलीज़ से पहले एग्ज़िट का पता लगाने के लिए, टेस्ट TEST_PREMATURE_EXIT_FILE के बताए गए पाथ पर फ़ाइल बना सकता है और बाहर निकलने पर उसे हटा सकता है. अगर जांच पूरी होने पर Baze फ़ाइल को देख लेता है, तो यह मान लिया जाएगा कि जांच समय से पहले ही बंद हो गई है और उसे 'हो गया' के तौर पर मार्क किया जाएगा.
टैग कन्वेंशन
जांच के नियमों में कुछ टैग का एक खास मतलब होता है. 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() नियम के कंपाइल होने में लगने वाले समय की डिपेंडेंसी के तौर पर बताया गया है. रनफ़ाइल डायरेक्ट्री, बिल्ड फ़ाइलों के उस सेट पर निर्भर करती है जो *_binary() नियम या इसके किसी कंपाइल-टाइम या रन-टाइम डिपेंडेंसी पर असर डालती है. सोर्स फ़ाइलों में बदलाव करने से, रनफ़ाइल डायरेक्ट्री की बनावट पर कोई असर नहीं पड़ता. इसलिए, इन फ़ाइलों को फिर से बनाने की प्रक्रिया भी शुरू नहीं होती.
विषय सूची
रनफ़ाइल डायरेक्ट्री में ये चीज़ें शामिल हैं:
- रन-टाइम डिपेंडेंसी के लिए सिमलिंक:
*_binary()नियम की रन-टाइम डिपेंडेंसी देने वाले हर OutputFile और CommandRule को रन-टाइम डायरेक्ट्री में एक सिमलिंक से दिखाया जाता है. सिमलिंक का नाम$(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()Z के लिए जो*_binary()C की रन-टाइम डिपेंडेंसी है, C की रनफ़ाइल डायरेक्ट्री में Z की रनफ़ाइल के लिए एक दूसरा लिंक होता है. सिमलिंक का नाम$(WORKSPACE)/package_name/rule_name.runfilesहै. सिमलिंक का टारगेट रनफ़ाइल डायरेक्ट्री है. उदाहरण के लिए, सभी सबप्रोग्राम एक ही रनफ़ाइल डायरेक्ट्री को शेयर करते हैं.