পরীক্ষা কার্যকর করার পরিবেশের একটি সম্পূর্ণ স্পেসিফিকেশন।
পটভূমি
Bazel BUILD ভাষায় এমন নিয়ম রয়েছে যা অনেক ভাষায় স্বয়ংক্রিয় পরীক্ষা প্রোগ্রাম সংজ্ঞায়িত করতে ব্যবহার করা যেতে পারে।
bazel test ব্যবহার করে পরীক্ষা চালানো হয়।
ব্যবহারকারীরা সরাসরি বাইনারি পরীক্ষা চালাতে পারে। এটি অনুমোদিত কিন্তু অনুমোদন করা হয় না, কারণ এই ধরনের আমন্ত্রণ নীচে বর্ণিত আদেশগুলি মেনে চলবে না৷
পরীক্ষাগুলি হারমেটিক হওয়া উচিত: অর্থাৎ, তাদের শুধুমাত্র সেই সম্পদগুলি অ্যাক্সেস করা উচিত যার উপর তাদের একটি ঘোষিত নির্ভরতা রয়েছে। যদি পরীক্ষাগুলি সঠিকভাবে হারমেটিক না হয় তবে তারা ঐতিহাসিকভাবে পুনরুত্পাদনযোগ্য ফলাফল দেয় না। অপরাধী খুঁজে বের করার জন্য এটি একটি উল্লেখযোগ্য সমস্যা হতে পারে (কোন পরিবর্তনটি পরীক্ষাটি ভেঙেছে তা নির্ধারণ করা), ইঞ্জিনিয়ারিং নিরীক্ষাযোগ্যতা প্রকাশ করা এবং পরীক্ষার রিসোর্স আইসোলেশন (স্বয়ংক্রিয় পরীক্ষার কাঠামো DDOS একটি সার্ভার নয় কারণ কিছু পরীক্ষা এটির সাথে কথা বলে)।
উদ্দেশ্য
এই পৃষ্ঠার লক্ষ্য হল আনুষ্ঠানিকভাবে Bazel পরীক্ষার জন্য এবং প্রত্যাশিত আচরণের জন্য রানটাইম পরিবেশ স্থাপন করা। এটি পরীক্ষার রানার এবং বিল্ড সিস্টেমের উপর প্রয়োজনীয়তা আরোপ করবে।
পরীক্ষার পরিবেশের স্পেসিফিকেশন পরীক্ষার লেখকদের অনির্দিষ্ট আচরণের উপর নির্ভর করা এড়াতে সাহায্য করে এবং এইভাবে পরীক্ষার পরিকাঠামোকে বাস্তবায়ন পরিবর্তন করার জন্য আরও স্বাধীনতা দেয়। স্পেসিফিকেশন কিছু ছিদ্রকে শক্ত করে যা বর্তমানে সঠিকভাবে হারমেটিক, নির্ধারক এবং পুনরায় প্রবেশকারী না হওয়া সত্ত্বেও অনেক পরীক্ষা পাস করতে দেয়।
এই পৃষ্ঠাটি আদর্শ এবং প্রামাণিক উভয়ের উদ্দেশ্যে করা হয়েছে। যদি এই স্পেসিফিকেশন এবং পরীক্ষার রানার বাস্তবায়িত আচরণ একমত না হয়, স্পেসিফিকেশন অগ্রাধিকার নেয়।
প্রস্তাবিত স্পেসিফিকেশন
"অবশ্যই", "অবশ্যই নয়", "প্রয়োজনীয়", "শালা", "শালা নয়", "উচিত", "উচিত নয়", "প্রস্তাবিত", "মেয়ে" এবং "ঐচ্ছিক" শব্দগুলোকে ব্যাখ্যা করতে হবে আইইটিএফ আরএফসি 2119 এ বর্ণিত।
পরীক্ষার উদ্দেশ্য
Bazel পরীক্ষার উদ্দেশ্য হল রিপোজিটরিতে চেক করা উৎস ফাইলগুলির কিছু সম্পত্তি নিশ্চিত করা। (এই পৃষ্ঠায়, "সোর্স ফাইল"-এ পরীক্ষার ডেটা, গোল্ডেন আউটপুট এবং সংস্করণ নিয়ন্ত্রণে রাখা অন্য কিছু অন্তর্ভুক্ত রয়েছে।) একজন ব্যবহারকারী একটি পরিবর্তনের দাবি করার জন্য একটি পরীক্ষা লেখেন যা তারা বজায় রাখার প্রত্যাশা করে। অন্য ব্যবহারকারীরা ইনভেরিয়ান্টটি ভাঙ্গা হয়েছে কিনা তা পরীক্ষা করার জন্য পরে পরীক্ষা চালায়। যদি পরীক্ষাটি সোর্স ফাইল (নন-হার্মেটিক) ব্যতীত অন্য কোনও ভেরিয়েবলের উপর নির্ভর করে, তবে এর মান হ্রাস পাবে, কারণ পরবর্তী ব্যবহারকারীরা নিশ্চিত হতে পারে না যে তাদের পরিবর্তনগুলি যখন পরীক্ষাটি পাস করা বন্ধ করে দেয় তখন তাদের ভুল ছিল।
অতএব একটি পরীক্ষার ফলাফল শুধুমাত্র নির্ভর করতে হবে:
- সোর্স ফাইল যার উপর পরীক্ষার একটি ঘোষিত নির্ভরতা রয়েছে
- বিল্ড সিস্টেমের পণ্য যার উপর পরীক্ষার একটি ঘোষিত নির্ভরতা রয়েছে
- সম্পদ যার আচরণ ধ্রুবক থাকার জন্য পরীক্ষা রানার দ্বারা নিশ্চিত করা হয়
বর্তমানে, এই ধরনের আচরণ প্রয়োগ করা হয় না। যাইহোক, পরীক্ষার রানাররা ভবিষ্যতে এই ধরনের প্রয়োগ যোগ করার অধিকার সংরক্ষণ করে।
বিল্ড সিস্টেমের ভূমিকা
পরীক্ষার নিয়মগুলি বাইনারি নিয়মগুলির সাথে সাদৃশ্যপূর্ণ যে প্রতিটিকে অবশ্যই একটি এক্সিকিউটেবল প্রোগ্রাম প্রদান করতে হবে। কিছু ভাষার জন্য, এটি একটি স্টাব প্রোগ্রাম যা পরীক্ষার কোডের সাথে একটি ভাষা-নির্দিষ্ট জোতাকে একত্রিত করে। পরীক্ষার নিয়মগুলি অবশ্যই অন্যান্য আউটপুট তৈরি করবে। প্রাথমিক পরীক্ষা নির্বাহযোগ্য ছাড়াও, পরীক্ষার রানারকে রানফাইলের একটি ম্যানিফেস্টের প্রয়োজন হবে, ইনপুট ফাইল যা রানটাইমে পরীক্ষার জন্য উপলব্ধ করা উচিত এবং এটির জন্য পরীক্ষার ধরন, আকার এবং ট্যাগ সম্পর্কে তথ্যের প্রয়োজন হতে পারে।
বিল্ড সিস্টেম কোডের পাশাপাশি ডেটা সরবরাহ করতে রানফাইলগুলি ব্যবহার করতে পারে। (এটি একটি অপ্টিমাইজেশান হিসাবে ব্যবহার করা যেতে পারে প্রতিটি পরীক্ষায় ফাইল শেয়ার করে বাইনারি ছোট করার জন্য, যেমন ডাইনামিক লিঙ্কিং ব্যবহার করে।) বিল্ড সিস্টেম নিশ্চিত করবে যে জেনারেট করা এক্সিকিউটেবল এই ফাইলগুলিকে পরীক্ষার দ্বারা প্রদত্ত রানফাইল ইমেজের মাধ্যমে লোড করে। রানার, উৎস বা আউটপুট ট্রিতে পরম অবস্থানের হার্ডকোড রেফারেন্সের পরিবর্তে।
টেস্ট রানার ভূমিকা
পরীক্ষার রানার দৃষ্টিকোণ থেকে, প্রতিটি পরীক্ষা একটি প্রোগ্রাম যা execve() দিয়ে আহ্বান করা যেতে পারে। পরীক্ষা চালানোর অন্যান্য উপায় থাকতে পারে; উদাহরণস্বরূপ, একটি IDE প্রক্রিয়াধীন জাভা পরীক্ষাগুলি সম্পাদনের অনুমতি দিতে পারে। যাইহোক, একটি স্বতন্ত্র প্রক্রিয়া হিসাবে পরীক্ষা চালানোর ফলাফল অবশ্যই প্রামাণিক হিসাবে বিবেচিত হবে। যদি একটি পরীক্ষা প্রক্রিয়া সম্পূর্ণ হওয়ার জন্য চলে এবং সাধারণত শূন্যের প্রস্থান কোডের সাথে সমাপ্ত হয়, তাহলে পরীক্ষাটি উত্তীর্ণ হয়েছে। অন্য কোন ফলাফল পরীক্ষা ব্যর্থ বলে বিবেচিত হয়। বিশেষ করে, STDout-এ PASS বা FAIL যেকোনও স্ট্রিং লেখার কোনো তাৎপর্য নেই টেস্ট রানারের কাছে।
যদি একটি পরীক্ষা চালানোর জন্য খুব বেশি সময় নেয়, কিছু সম্পদের সীমা অতিক্রম করে, বা পরীক্ষার রানার অন্যথায় নিষিদ্ধ আচরণ শনাক্ত করে, তাহলে এটি পরীক্ষাটিকে মেরে ফেলতে এবং রানটিকে ব্যর্থ হিসাবে বিবেচনা করতে পারে। রানার পরীক্ষা প্রক্রিয়া বা তার কোনো শিশুর জন্য একটি সংকেত পাঠানোর পরে পরীক্ষা পাস হিসাবে রিপোর্ট করা উচিত নয়.
সম্পূর্ণ পরীক্ষার লক্ষ্যমাত্রা (ব্যক্তিগত পদ্ধতি বা পরীক্ষা নয়) সম্পূর্ণ করার জন্য সীমিত পরিমাণ সময় দেওয়া হয়। একটি পরীক্ষার জন্য সময়সীমা নিম্নলিখিত সারণী অনুযায়ী তার timeout বৈশিষ্ট্যের উপর ভিত্তি করে:
| সময় শেষ | সময়সীমা (সেকেন্ড) |
|---|---|
| সংক্ষিপ্ত | 60 |
| মধ্যপন্থী | 300 |
| দীর্ঘ | 900 |
| চিরন্তন | 3600 |
যে পরীক্ষাগুলি স্পষ্টভাবে একটি টাইমআউট নির্দিষ্ট করে না সেগুলি নিম্নরূপ পরীক্ষার size উপর ভিত্তি করে উহ্য থাকে:
| আকার | উহ্য টাইমআউট লেবেল |
|---|---|
| ছোট | সংক্ষিপ্ত |
| মধ্যম | মধ্যপন্থী |
| বড় | দীর্ঘ |
| বিশাল | চিরন্তন |
কোন সুস্পষ্ট টাইমআউট সেটিং ছাড়া একটি "বড়" পরীক্ষা চালানোর জন্য 900 সেকেন্ড বরাদ্দ করা হবে। "সংক্ষিপ্ত" সময়সীমা সহ একটি "মাঝারি" পরীক্ষা 60 সেকেন্ড বরাদ্দ করা হবে।
timeout বিপরীতে, সাধারণ সংজ্ঞায় বর্ণিত হিসাবে স্থানীয়ভাবে পরীক্ষা চালানোর সময় size অন্যান্য সংস্থানগুলির (যেমন RAM) অনুমিত সর্বোচ্চ ব্যবহার নির্ধারণ করে।
size এবং timeout লেবেলের সমস্ত সমন্বয় আইনী, তাই একটি "বিশাল" পরীক্ষাকে "সংক্ষিপ্ত" সময়সীমা ঘোষণা করা যেতে পারে। সম্ভবত এটি খুব দ্রুত কিছু সত্যিই ভয়ঙ্কর জিনিস করবে।
সময়সীমা নির্বিশেষে পরীক্ষাগুলি ইচ্ছামত দ্রুত ফিরে আসতে পারে। অতিরিক্ত সময়সীমার জন্য একটি পরীক্ষাকে শাস্তি দেওয়া হয় না, যদিও একটি সতর্কতা জারি করা হতে পারে: আপনার সাধারণত কোন ফ্লিকনেস না করেই আপনার টাইমআউট যতটা সম্ভব শক্তভাবে সেট করা উচিত।
ধীর বলে পরিচিত অবস্থার অধীনে ম্যানুয়ালি চালানোর সময় পরীক্ষার সময়সীমা --test_timeout বেজেল পতাকা দিয়ে ওভাররাইড করা যেতে পারে। --test_timeout মান সেকেন্ডে হয়। উদাহরণস্বরূপ, --test_timeout=120 পরীক্ষার সময়সীমা দুই মিনিটে সেট করে।
নিম্নরূপ পরীক্ষার সময়সীমার জন্য একটি প্রস্তাবিত নিম্ন সীমা রয়েছে:
| সময় শেষ | সর্বনিম্ন সময় (সেকেন্ড) |
|---|---|
| সংক্ষিপ্ত | 0 |
| মধ্যপন্থী | 30 |
| দীর্ঘ | 300 |
| চিরন্তন | 900 |
উদাহরণস্বরূপ, যদি একটি "মধ্যম" পরীক্ষা 5.5 সেকেন্ডে শেষ হয়, তাহলে timeout = "short" বা size = "small" সেটিং বিবেচনা করুন। bazel --test_verbose_timeout_warnings কমান্ড লাইন বিকল্প ব্যবহার করে পরীক্ষাগুলি দেখাবে যার নির্দিষ্ট আকার খুব বড়।
এখানে স্পেসিফিকেশন অনুযায়ী বিল্ড ফাইলে পরীক্ষার মাপ এবং সময়সীমা নির্দিষ্ট করা হয়েছে। অনির্দিষ্ট হলে, একটি পরীক্ষার আকার ডিফল্ট হবে "মাঝারি"।
যদি একটি পরীক্ষার মূল প্রক্রিয়াটি বেরিয়ে যায়, কিন্তু এর কিছু শিশু এখনও চলছে, তবে পরীক্ষার রানারকে রানটিকে সম্পূর্ণ বিবেচনা করা উচিত এবং মূল প্রক্রিয়া থেকে পর্যবেক্ষণ করা প্রস্থান কোডের ভিত্তিতে এটিকে সাফল্য বা ব্যর্থতা হিসাবে গণনা করা উচিত। পরীক্ষার রানার যেকোন বিপথগামী প্রক্রিয়াকে মেরে ফেলতে পারে। পরীক্ষার এই পদ্ধতিতে প্রক্রিয়াগুলি ফাঁস করা উচিত নয়।
টেস্ট শার্ডিং
টেস্ট শর্ডিংয়ের মাধ্যমে পরীক্ষাগুলি সমান্তরাল করা যেতে পারে। পরীক্ষা শার্ডিং সক্ষম করতে --test_sharding_strategy এবং shard_count দেখুন। যখন শর্ডিং সক্ষম করা হয়, তখন প্রতি শার্ডে একবার পরীক্ষামূলক রানার চালু করা হয়। এনভায়রনমেন্ট ভেরিয়েবল TEST_TOTAL_SHARDS হল শার্ডের সংখ্যা, এবং TEST_SHARD_INDEX হল শার্ড সূচক, 0 থেকে শুরু হয়। কোন পরীক্ষা চালানো হবে তা নির্বাচন করতে দৌড়বিদরা এই তথ্য ব্যবহার করে - উদাহরণস্বরূপ, রাউন্ড-রবিন কৌশল ব্যবহার করে। সব টেস্ট রানার শার্ডিং সমর্থন করে না। যদি একজন রানার শার্ডিং সমর্থন করে, তাহলে তাকে অবশ্যই TEST_SHARD_STATUS_FILE দ্বারা নির্দিষ্ট করা ফাইলের শেষ পরিবর্তিত তারিখটি তৈরি বা আপডেট করতে হবে। অন্যথায়, Bazel অনুমান করে যে এটি শার্ডিং সমর্থন করে না এবং অতিরিক্ত রানার চালু করবে না।
প্রাথমিক শর্তাবলি
একটি পরীক্ষা চালানোর সময়, পরীক্ষার রানারকে অবশ্যই কিছু প্রাথমিক শর্ত স্থাপন করতে হবে।
পরীক্ষার রানারকে অবশ্যই argv[0] -এ এক্সিকিউটেবল পরীক্ষার পাথ সহ প্রতিটি পরীক্ষা করতে হবে। এই পথটি অবশ্যই আপেক্ষিক হতে হবে এবং পরীক্ষার বর্তমান ডিরেক্টরির নীচে (যা রানফাইলস ট্রিতে রয়েছে, নীচে দেখুন)। ব্যবহারকারী স্পষ্টভাবে অনুরোধ না করলে পরীক্ষায় রানারকে অন্য কোনো আর্গুমেন্ট পরীক্ষায় পাস করা উচিত নয়।
প্রাথমিক পরিবেশ ব্লক নিম্নরূপ গঠিত হবে:
| পরিবর্তনশীল | মান | স্ট্যাটাস |
|---|---|---|
HOME | $TEST_TMPDIR এর মান | প্রস্তাবিত |
LANG | আনসেট | প্রয়োজনীয় |
LANGUAGE | আনসেট | প্রয়োজনীয় |
LC_ALL | আনসেট | প্রয়োজনীয় |
LC_COLLATE | আনসেট | প্রয়োজনীয় |
LC_CTYPE | আনসেট | প্রয়োজনীয় |
LC_MESSAGES | আনসেট | প্রয়োজনীয় |
LC_MONETARY | আনসেট | প্রয়োজনীয় |
LC_NUMERIC | আনসেট | প্রয়োজনীয় |
LC_TIME | আনসেট | প্রয়োজনীয় |
LD_LIBRARY_PATH | শেয়ার্ড লাইব্রেরি ধারণকারী ডিরেক্টরিগুলির কোলন-বিচ্ছিন্ন তালিকা | ঐচ্ছিক |
JAVA_RUNFILES | $TEST_SRCDIR এর মান | অবমূল্যায়ন |
LOGNAME | $USER এর মান | প্রয়োজনীয় |
PATH | /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. | প্রস্তাবিত |
PWD | $TEST_SRCDIR/ workspace-name | প্রস্তাবিত |
SHLVL | 2 | প্রস্তাবিত |
TEST_INFRASTRUCTURE_FAILURE_FILE | একটি লিখনযোগ্য ডিরেক্টরিতে একটি ব্যক্তিগত ফাইলের পরম পথ (এই ফাইলটি শুধুমাত্র পরীক্ষার পরিকাঠামো থেকে উদ্ভূত ব্যর্থতার রিপোর্ট করার জন্য ব্যবহার করা উচিত, পরীক্ষার ফ্ল্যাকি ব্যর্থতা রিপোর্ট করার জন্য একটি সাধারণ প্রক্রিয়া হিসাবে নয়। এই প্রসঙ্গে, পরীক্ষার পরিকাঠামোকে সিস্টেম বা লাইব্রেরি হিসাবে সংজ্ঞায়িত করা হয় যেগুলি পরীক্ষা-নির্দিষ্ট নয়, কিন্তু ত্রুটিপূর্ণ হয়ে পরীক্ষায় ব্যর্থতার কারণ হতে পারে৷ প্রথম লাইনটি পরীক্ষার পরিকাঠামো উপাদানের নাম যা ব্যর্থতার কারণ, দ্বিতীয়টি ব্যর্থতার মানব-পাঠযোগ্য বর্ণনা৷ অতিরিক্ত লাইন উপেক্ষা করা হয়৷) | ঐচ্ছিক |
TEST_LOGSPLITTER_OUTPUT_FILE | একটি লিখনযোগ্য ডিরেক্টরিতে একটি ব্যক্তিগত ফাইলের পরম পথ (লগস্প্লিটার প্রোটোবাফার লগ লিখতে ব্যবহৃত) | ঐচ্ছিক |
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 | sharding ব্যবহার করা হলে মোট shard count | ঐচ্ছিক |
TEST_TMPDIR | একটি ব্যক্তিগত লিখনযোগ্য ডিরেক্টরির পরম পথ | প্রয়োজনীয় |
TEST_WORKSPACE | স্থানীয় সংগ্রহস্থলের কর্মক্ষেত্রের নাম | ঐচ্ছিক |
TEST_UNDECLARED_OUTPUTS_DIR | একটি ব্যক্তিগত লিখনযোগ্য ডিরেক্টরির পরম পথ (অঘোষিত পরীক্ষার আউটপুট লিখতে ব্যবহৃত) | ঐচ্ছিক |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR | একটি ব্যক্তিগত লিখনযোগ্য ডিরেক্টরির পরম পথ (অঘোষিত পরীক্ষার আউটপুট টীকা লিখতে ব্যবহৃত হয় . .pb .part )। | ঐচ্ছিক |
TEST_WARNINGS_OUTPUT_FILE | একটি লিখনযোগ্য ডিরেক্টরিতে একটি ব্যক্তিগত ফাইলের পরম পথ (পরীক্ষা লক্ষ্য সতর্কতা লিখতে ব্যবহৃত) | ঐচ্ছিক |
TESTBRIDGE_TEST_ONLY | --test_filter এর মান, যদি নির্দিষ্ট করা থাকে | ঐচ্ছিক |
TZ | UTC | প্রয়োজনীয় |
USER | getpwuid(getuid())->pw_name এর মান | প্রয়োজনীয় |
XML_OUTPUT_FILE | অবস্থান যেখানে পরীক্ষার ক্রিয়াগুলি একটি পরীক্ষার ফলাফল XML আউটপুট ফাইল লিখতে হবে৷ অন্যথায়, Bazel একটি ডিফল্ট XML আউটপুট ফাইল তৈরি করে যা পরীক্ষার ক্রিয়াকলাপের অংশ হিসাবে পরীক্ষার লগকে মোড়ানো হয়। XML স্কিমা 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 | সীমাহীন, অথবা 2044KB <= rlim <= 8192KB |
প্রাথমিক প্রক্রিয়ার সময়গুলি (যেমনটি times() দ্বারা ফেরত দেওয়া হয়) এবং সংস্থান ব্যবহার (যেমন getrusage() দ্বারা প্রত্যাবর্তিত হয়) অনির্দিষ্ট।
প্রাথমিক সময়সূচী নীতি এবং অগ্রাধিকার অনির্দিষ্ট.
হোস্ট সিস্টেমের ভূমিকা
টেস্ট রানারের সরাসরি নিয়ন্ত্রণের অধীনে ব্যবহারকারীর প্রেক্ষাপটের দিকগুলি ছাড়াও, যে অপারেটিং সিস্টেমের উপর পরীক্ষা চালানো হয় সেটিকে অবশ্যই বৈধ হওয়ার জন্য নির্দিষ্ট বৈশিষ্ট্যগুলি পূরণ করতে হবে।
নথি ব্যবস্থা
একটি পরীক্ষার দ্বারা পর্যবেক্ষণ করা রুট ডিরেক্টরিটি প্রকৃত রুট ডিরেক্টরি হতে পারে বা নাও হতে পারে।
/proc মাউন্ট করা হবে।
স্থানীয় ইনস্টলেশন দ্বারা ব্যবহৃত /usr এর অধীনে পরম পাথগুলিতে সমস্ত বিল্ড সরঞ্জাম উপস্থিত থাকবে।
/home দিয়ে শুরু হওয়া পাথগুলি উপলব্ধ নাও হতে পারে৷ পরীক্ষার এই ধরনের কোনো পাথ অ্যাক্সেস করা উচিত নয়।
/tmp লেখার যোগ্য, কিন্তু পরীক্ষাগুলি এই পাথগুলি ব্যবহার করা এড়ানো উচিত।
পরীক্ষাগুলিকে অনুমান করা উচিত নয় যে কোনও ধ্রুবক পথ তাদের একচেটিয়া ব্যবহারের জন্য উপলব্ধ।
পরীক্ষাগুলিকে অনুমান করা উচিত নয় যে কোনো মাউন্ট করা ফাইল সিস্টেমের জন্য atimes সক্রিয় করা হয়েছে।
ব্যবহারকারী এবং গ্রুপ
ব্যবহারকারীদের root, nobody, এবং unittest অবশ্যই বিদ্যমান থাকতে হবে। গ্রুপ root, nobody, এবং eng অবশ্যই বিদ্যমান থাকবে।
একটি নন-রুট ব্যবহারকারী হিসাবে পরীক্ষাগুলি সম্পাদন করা আবশ্যক। প্রকৃত এবং কার্যকর ব্যবহারকারী আইডি সমান হতে হবে; একইভাবে গ্রুপ আইডির জন্য। এর বাইরে, বর্তমান ব্যবহারকারী আইডি, গ্রুপ আইডি, ব্যবহারকারীর নাম এবং গ্রুপের নাম অনির্দিষ্ট। পরিপূরক গ্রুপ আইডির সেটটি অনির্দিষ্ট।
বর্তমান ব্যবহারকারী আইডি এবং গ্রুপ আইডিতে অবশ্যই সংশ্লিষ্ট নাম থাকতে হবে যা getpwuid( getpwuid() এবং getgrgid() দিয়ে পুনরুদ্ধার করা যেতে পারে। সম্পূরক গ্রুপ আইডির ক্ষেত্রেও এটি সত্য নাও হতে পারে।
বর্তমান ব্যবহারকারীর অবশ্যই একটি হোম ডিরেক্টরি থাকতে হবে। এটা লেখার যোগ্য নাও হতে পারে। পরীক্ষা অবশ্যই এটি লেখার চেষ্টা করা উচিত নয়।
নেটওয়ার্কিং
হোস্টনামটি অনির্দিষ্ট। এটিতে একটি বিন্দু থাকতে পারে বা নাও থাকতে পারে। হোস্টনাম সমাধান করার জন্য বর্তমান হোস্টের একটি আইপি ঠিকানা দিতে হবে। প্রথম বিন্দুর পরে হোস্টনাম কাটার সমাধান করাও অবশ্যই কাজ করবে। হোস্টনাম লোকালহোস্ট অবশ্যই সমাধান করতে হবে।
অন্যান্য উৎস
পরীক্ষা অন্তত একটি CPU কোর দেওয়া হয়. অন্যরা উপলব্ধ হতে পারে তবে এটি নিশ্চিত নয়। এই কোরের অন্যান্য কর্মক্ষমতা দিক নির্দিষ্ট করা হয় না। আপনি একটি পরীক্ষার নিয়মে "cpu:n" ট্যাগ (যেখানে n একটি ইতিবাচক সংখ্যা) যোগ করে সিপিইউ কোরের একটি উচ্চ সংখ্যায় সংরক্ষণ বাড়াতে পারেন। একটি মেশিনে অনুরোধের চেয়ে কম মোট CPU কোর থাকলে, Bazel এখনও পরীক্ষা চালাবে। যদি একটি পরীক্ষায় শার্ডিং ব্যবহার করা হয়, প্রতিটি পৃথক শার্ড এখানে নির্দিষ্ট করা CPU কোরের সংখ্যা সংরক্ষণ করবে।
পরীক্ষাগুলি সাবপ্রসেস তৈরি করতে পারে, কিন্তু গোষ্ঠী বা সেশন প্রক্রিয়া নয়।
একটি পরীক্ষা গ্রহণ করতে পারে এমন ইনপুট ফাইলের সংখ্যার একটি সীমা রয়েছে৷ এই সীমা পরিবর্তন সাপেক্ষে, কিন্তু বর্তমানে হাজার হাজার ইনপুটের সীমার মধ্যে রয়েছে।
সময় এবং তারিখ
বর্তমান সময় এবং তারিখ অনির্দিষ্ট। সিস্টেম টাইমজোন অনির্দিষ্ট।
X উইন্ডোজ উপলব্ধ হতে পারে বা নাও হতে পারে। যে পরীক্ষাগুলির জন্য একটি X সার্ভার প্রয়োজন সেগুলি Xvfb শুরু করা উচিত।
ফাইল সিস্টেমের সাথে ইন্টারঅ্যাকশন পরীক্ষা করুন
পরীক্ষার পরিবেশ ভেরিয়েবলে নির্দিষ্ট করা সমস্ত ফাইল পাথ স্থানীয় ফাইল সিস্টেমের কোথাও নির্দেশ করে, যদি না অন্যথায় নির্দিষ্ট করা হয়।
টেস্টগুলি শুধুমাত্র $TEST_TMPDIR এবং $TEST_UNDECLARED_OUTPUTS_DIR (যদি সেট) দ্বারা নির্দিষ্ট করা ডিরেক্টরিগুলির মধ্যে ফাইলগুলি তৈরি করবে৷
এই ডিরেক্টরিগুলি প্রাথমিকভাবে খালি থাকবে।
পরীক্ষাগুলি অবশ্যই এই ডিরেক্টরিগুলিকে অপসারণ, chmod বা অন্যথায় পরিবর্তন করার চেষ্টা করবে না।
এই ডিরেক্টরিগুলি একটি প্রতীকী লিঙ্ক হতে পারে।
$TEST_TMPDIR/. অনির্দিষ্ট থেকে যায়।
অঘোষিত আউটপুট ফাইলগুলিকে টীকা দেওয়ার জন্য $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR এ .part ফাইলগুলিও লিখতে পারে৷
বিরল ক্ষেত্রে, /tmp এ ফাইল তৈরি করতে একটি পরীক্ষা বাধ্য করা হতে পারে। উদাহরণস্বরূপ, ইউনিক্স ডোমেইন সকেটের পাথের দৈর্ঘ্যের সীমার জন্য সাধারণত /tmp এর অধীনে সকেট তৈরি করা প্রয়োজন। Bazel এই ধরনের ফাইল ট্র্যাক করতে অক্ষম হবে; পরীক্ষাটিকে অবশ্যই যত্নবান হতে হবে, অন্যদের সাথে সংঘর্ষ এড়াতে অনন্য পাথ ব্যবহার করতে হবে, একই সাথে পরীক্ষা এবং নন-টেস্ট প্রসেসগুলি চালাতে হবে এবং /tmp এ তৈরি করা ফাইলগুলি পরিষ্কার করতে হবে।
কিছু জনপ্রিয় টেস্টিং ফ্রেমওয়ার্ক, যেমন JUnit4 TemporaryFolder বা TempDir TempDir, /tmp এর অধীনে একটি অস্থায়ী ডিরেক্টরি তৈরি করার নিজস্ব উপায় রয়েছে। এই টেস্টিং ফ্রেমওয়ার্কগুলির মধ্যে এমন কার্যকারিতা রয়েছে যা /tmp tmp-এ ফাইলগুলি পরিষ্কার করে, তাই আপনি সেগুলি ব্যবহার করতে পারেন যদিও তারা TEST_TMPDIR এর বাইরে ফাইল তৈরি করে।
টেস্টগুলিকে অবশ্যই রানফাইল মেকানিজম বা এক্সিকিউশন এনভায়রনমেন্টের অন্যান্য অংশের মাধ্যমে ইনপুট অ্যাক্সেস করতে হবে যা বিশেষভাবে ইনপুট ফাইলগুলিকে উপলব্ধ করার উদ্দেশ্যে তৈরি করা হয়।
পরীক্ষাগুলি তাদের নিজস্ব এক্সিকিউটেবলের অবস্থান থেকে অনুমান করা পাথগুলিতে বিল্ড সিস্টেমের অন্যান্য আউটপুটগুলি অ্যাক্সেস করতে হবে না।
রানফাইলস ট্রিতে নিয়মিত ফাইল, সিম্বলিক লিঙ্ক বা মিশ্রণ আছে কিনা তা অনির্দিষ্ট। রানফাইলস ট্রিতে ডিরেক্টরির সিমলিঙ্ক থাকতে পারে। রানফাইল ট্রির মধ্যে .. উপাদান ধারণকারী পাথ ব্যবহার করা পরীক্ষায় এড়ানো উচিত।
রানফাইলস ট্রির মধ্যে কোনো ডিরেক্টরি, ফাইল বা সিমলিঙ্ক (যেসব পাথগুলি সিমলিঙ্কগুলিকে অতিক্রম করে) লেখার যোগ্য হওয়া উচিত নয়। (এটি অনুসরণ করে যে প্রাথমিক কার্যকারী ডিরেক্টরি লেখার যোগ্য হবে না।) পরীক্ষাগুলিকে অনুমান করা উচিত নয় যে রানফাইলের কোনো অংশ লেখার যোগ্য, বা বর্তমান ব্যবহারকারীর মালিকানাধীন (উদাহরণস্বরূপ, chmod এবং chgrp ব্যর্থ হতে পারে)।
রানফাইলস ট্রি (পাথ সহ যা সিমলিংক অতিক্রম করে) পরীক্ষা চালানোর সময় পরিবর্তন করা উচিত নয়। প্যারেন্ট ডিরেক্টরি এবং ফাইল-সিস্টেম মাউন্টগুলিকে কোনোভাবেই পরিবর্তন করা উচিত নয় যা রানফাইলস ট্রির মধ্যে একটি পাথ সমাধানের ফলাফলকে প্রভাবিত করে।
তাড়াতাড়ি প্রস্থান ধরার জন্য, একটি পরীক্ষা শুরু করার পরে TEST_PREMATURE_EXIT_FILE দ্বারা নির্দিষ্ট করা পাথে একটি ফাইল তৈরি করতে পারে এবং প্রস্থান করার পরে এটি সরিয়ে ফেলতে পারে৷ পরীক্ষা শেষ হলে Bazel ফাইলটি দেখতে পেলে, এটি ধরে নেবে যে পরীক্ষাটি সময়ের আগেই প্রস্থান করেছে এবং এটি ব্যর্থ হয়েছে বলে চিহ্নিত করবে।
ট্যাগ কনভেনশন
পরীক্ষার নিয়মে কিছু ট্যাগের একটি বিশেষ অর্থ রয়েছে। 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() নিয়মের কম্পাইল-টাইম নির্ভরতা হিসাবে ঘোষণা করা হয়। রানফাইলস ডিরেক্টরি নিজেই BUILD ফাইলের সেটের উপর নির্ভর করে যা *_binary() নিয়ম বা এর যেকোন কম্পাইল-টাইম বা রান-টাইম নির্ভরতাকে প্রভাবিত করে। সোর্স ফাইলগুলি পরিবর্তন করা রানফাইল ডিরেক্টরির গঠনকে প্রভাবিত করে না এবং এইভাবে কোনো পুনর্নির্মাণকে ট্রিগার করে না।
বিষয়বস্তু
রানফাইলস ডিরেক্টরিতে নিম্নলিখিতগুলি রয়েছে:
- রান-টাইম নির্ভরতার সিমলিংক: প্রতিটি আউটপুটফাইল এবং কমান্ডরুল যা
*_binary()নিয়মের রান-টাইম নির্ভরতা, রানফাইল ডিরেক্টরিতে একটি সিমলিংক দ্বারা প্রতিনিধিত্ব করা হয়। সিমলিংকের নাম হল$(WORKSPACE)/package_name/rule_name। উদাহরণস্বরূপ, সার্ভারের সিমলিংকের নাম হবে$(WORKSPACE)/deps/server/server, এবং সম্পূর্ণ পথটি হবে$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. সিমলিংকের গন্তব্য হল OutputFileName() এর OutputFile বা CommandRule, যা একটি পরম পথ হিসাবে প্রকাশ করা হয়। সুতরাং, সিমলিংকের গন্তব্য$(WORKSPACE)/linux-dbg/deps/server/42/serverহতে পারে। - সাব-রানফাইলের সিমলিংক : প্রতিটি
*_binary()Z-এর জন্য যা*_binary()C-এর রান-টাইম নির্ভরতা, C-এর রানফাইল ডিরেক্টরিতে Z-এর রানফাইলগুলির সাথে একটি দ্বিতীয় লিঙ্ক রয়েছে। সিমলিংকের নাম হল$(WORKSPACE)/package_name/rule_name.runfiles। সিমলিংকের লক্ষ্য রানফাইলস ডিরেক্টরি। উদাহরণস্বরূপ, সমস্ত সাবপ্রোগ্রাম একটি সাধারণ রানফাইল ডিরেক্টরি ভাগ করে।