اختبار الموسوعة

مواصفات شاملة لبيئة تنفيذ الاختبار.

الخلفية

تتضمّن لغة Bazel BUILD قواعد يمكن استخدامها لتحديد برامج الاختبار المبرمَجة بلغات متعدّدة.

يتم إجراء الاختبارات باستخدام bazel test.

ويمكن للمستخدمين أيضًا تنفيذ برامج ثنائية للاختبار مباشرةً. ويُسمح بذلك ولكن لم تتمّ الموافقة عليه، لأنّ هذا الاستدعاء لا يتقيّد بالتفويضات الموضّحة أدناه.

يجب أن تكون الاختبارات متناسقة، أي أنّه يجب الوصول إلى الموارد التي يعتمد عليها الاعتماد فقط. وإذا لم تكن الاختبارات متماثلة بشكل صحيح، فلن تقدم نتائج قابلة للتكرار في المستقبل. وقد يشكّل ذلك مشكلة كبيرة في العثور على الجسيمات (أي تحديد التغيير الذي يعرقل الاختبار) وتدقيق التدقيق في الهندسة الهندسية، وعزل الموارد للاختبارات (أُطر عمل الاختبار المبرمَجة لا تؤدي إلى خادم DDOS، لأنّ بعض الاختبارات تتحدّث إليه).

الغرض

والهدف من هذه الصفحة هو إنشاء بيئة وقت التشغيل بشكل رسمي لإجراء اختبارات Bazel والسلوك المتوقّع لها. وستفرض أيضًا هذه المتطلبات على المختبر ونظام الإصدار.

وتساعد مواصفات بيئة الاختبار مؤلفي الاختبار على تجنب الاعتماد على سلوك غير محدّد، ما يمنح البنية الأساسية للاختبار مزيدًا من الحرية لإجراء تغييرات التنفيذ. تعمل المواصفات على تشدّد بعض الثقوب التي تسمح حاليًا باجتياز العديد من الاختبارات على الرغم من أنها غير مُحدَّدة ومنهِرة ومحددة بشكل صحيح.

وتهدف هذه الصفحة إلى أن تكون رسمية وموثوقة. إذا اختلف هذا المواصفات والسلوك المنفَّذ للعدّاء، تكون الأولوية للمواصفات.

المواصفات المقترحة

"الكلمات الرئيسية" و"&" و"MUST" و"&";";MUST NOT""&";";&;;;;;;;SHALL",&";;ALLALL&&;;&&;;OUOU&&;;;&&;;OUOULD NOT","recommended"&&;;quot;MAY";و##[##]; ##] وما إلى ذلك:

الغرض من الاختبارات

يتمثل الغرض من اختبارات Bazel في تأكيد ملكية ملفات المصدر التي تم التحقق منها في المستودع. (في هذه الصفحة، تتضمّن "ملفات المصدر"بيانات الاختبار والمخرجات الذهبية وأي شيء آخر يتم الاحتفاظ به ضمن التحكّم في الإصدارات). ويكتب أحد المستخدمين اختبارًا للتأكّد من الأنماط الثابتة التي يتوقع أن تتم الاحتفاظ بها. وينفّذ المستخدمون الآخرون الاختبار لاحقًا للتحقق من تعطّل المتغير. إذا كان الاختبار يعتمد على أي متغيّرات أخرى غير ملفات المصدر (غير متناسقة)، يتم تقليل قيمته لأنّ المستخدمين في وقت لاحق لا يمكنهم التأكّد من أنّ تغييراتهم تتضمّن أخطاءً عندما يتوقف الاختبار.

وبالتالي، يجب أن تعتمد نتيجة الاختبار على ما يلي فقط:

• ملفات المصدر التي يعتمد عليها الاختبار
• منتجات نظام الإصدار الذي يعتمد عليه الاختبار اعتمادًا
• الموارد التي يضمن سلوكها الشخص الذي يجري الاختبار أن يظل ثابتًا

وفي الوقت الحالي، لا يتم فرض هذا السلوك. ومع ذلك، يحتفظ الحاكمون بالحق في إضافة هذا التنفيذ في المستقبل.

دور نظام الإصدار

تشبه قواعد الاختبار القواعد الثنائية في أنها يجب أن تؤدي إلى برنامج تنفيذي. بالنسبة إلى بعض اللغات، هذا البرنامج هو برنامج بديل يتضمّن مجموعة رموز خاصة باللغات مع رمز الاختبار. ويجب أن تؤدي قواعد الاختبار إلى مخرجات أخرى أيضًا. بالإضافة إلى الملف التنفيذي للاختبار الأساسي، سيحتاج تشغيل الاختبار إلى بيان runfiles، وملفات الإدخال التي يجب أن تكون متاحة للاختبار في وقت التشغيل، وقد يحتاج إلى معلومات حول نوع الاختبار وحجمه وعلاماته.

قد يستخدم نظام الإصدار ملفات run to run code and data. (يمكن استخدام هذا كتحسين لتصغير كل برنامج ثنائي تجريبي من خلال مشاركة ملفات عبر الاختبارات، مثلاً من خلال استخدام الربط الديناميكي.) يجب أن يتأكّد نظام الإصدار من أنّ الملف التنفيذي الذي يتم إنشاؤه يحمّل هذه الملفات من خلال صورة runfiles التي يوفّرها عامل التشغيل التجريبي، بدلاً من المراجع الثابتة الترميز للمواقع الجغرافية المطلقة في المصدر أو شجرة النتائج.

دور الشخص الذي يجري الاختبار

من منظور مُجري الاختبار، كل اختبار هو برنامج يمكن استدعاؤه باستخدام execve(). قد تكون هناك طرق أخرى لتنفيذ الاختبارات، على سبيل المثال، قد يسمح بيئة التطوير المتكاملة (IDE) بتنفيذ اختبارات Java أثناء المعالجة. ولكن تُعتبر نتيجة إجراء الاختبار كعملية مستقلة مستقلة. إذا اكتملت عملية الاختبار وانتهت بشكل طبيعي برمز خروج كان صفرًا، يتمّ اجتياز الاختبار. يتم اعتبار أي نتيجة أخرى خطأ في الاختبار. وعلى وجه الخصوص، فإن كتابة أي من السلاسل PASS أو FAIL في stdout ليس لها أي أهمية على الشخص الذي يجري الاختبار.

إذا استغرق تنفيذ الاختبار وقتًا طويلاً جدًا، أو تجاوز بعض الحدود القصوى للموارد، أو إذا اكتشف تشغيل الاختبار سلوكًا محظورًا، قد يختار إنهاء الاختبار وتنفيذه كإخفاق. يجب ألا يبلّغ الشخص الذي يجري الاختبار عن الاختبار بعد اجتيازه إرسال إشارة إلى عملية الاختبار أو إلى أي أطفال خارجها.

ويتم منح الهدف التجريبي الكامل (وليس طرقًا فردية أو اختبارات) لفترة محدودة من الوقت لإكماله. يعتمد الحدّ الزمني للاختبار على سمة timeout الخاصة به وفقًا للجدول التالي:

انتهت المهلة	الحد الزمني (بالثواني)
فيديو قصير	60
معتدل	300
شعر طويل	900
الأبد	3,600

تحتوي الاختبارات التي لا تحدِّد المهلة صراحةً على ضمني استنادًا إلى size اختباري' على النحو التالي:

size	تصنيف المهلة الضمنية
صغير	فيديو قصير
متوسط	معتدل
كبير	شعر طويل
ضَخْم	الأبد

سيتم تخصيص الاختبار "large" بدون ضبط المهلة الصريحة لمدة 900 ثانية. سيتم تخصيص مدة الاختبار &"الوسيط" مع مهلة "quot;short" 60 ثانية.

وعلى عكس timeout، يحدد size بالإضافة إلى ذلك ذروة الاستخدام للموارد الأخرى (مثل ذاكرة الوصول العشوائي) عند إجراء الاختبار محليًا، كما هو موضح في التعريفات الشائعة.

إنّ جميع مجموعات size وtimeout قانونية، لذلك قد يتم الإعلان عن &quot:&hl=ar&quot:اختبار أن المهلة المحددة لـ "short". من المفترض أن يؤدي هذا الإجراء إلى تنفيذ بعض الأمور الرهيبة بسرعة كبيرة.

وقد يتم عرض الاختبارات بشكل عشوائي بغض النظر عن المهلة. لا يتم فرض عقوبات على الاختبار بالنسبة إلى المهلة الزائدة، على الرغم من أنه قد يتم إصدار تحذير: يجب بوجه عام ضبط المهلة على أكبر قدر ممكن من أضيق الحدود بدون حدوث أي تقلبات.

يمكن إلغاء انتهاء مهلة الاختبار باستخدام علامة بازار --test_timeout عند التشغيل يدويًا في ظل ظروف معروفة أنها بطيئة. تظهر قيم --test_timeout بالثواني. على سبيل المثال، تضبط --test_timeout=120 مهلة الاختبار على دقيقتين.

هناك أيضًا حد أدنى مقترح لمهلة الاختبار على النحو التالي:

انتهت المهلة	الحد الأدنى للوقت (بالثواني)
فيديو قصير	0
معتدل	30
شعر طويل	300
الأبد	900

على سبيل المثال، إذا اكتمل الاختبار "moderate" في 5.5 ثوانٍ، ننصحك بإعداد timeout = "short" أو size = "small". يؤدي استخدام خيار سطر الأوامر في --test_verbose_timeout_warnings إلى عرض الاختبارات التي يكون حجمها المحدّد كبيرًا جدًا.

يتم تحديد أحجام الاختبارات والمهلات في ملف BUILD وفقًا للمواصفات هنا. إذا لم يتم تحديد حجم، سيتم ضبط حجم الاختبار تلقائيًا على "medium".

إذا خرجت العملية الرئيسية من الاختبار، ولكن لا يزال بعض أطفاله قيد التشغيل، على المستخدم الذي يجري الاختبار أن يعتبر الركض مكتملاً ويتم احتسابه على أنه ناجح أو فشل استنادًا إلى رمز الخروج الذي تمت ملاحظته من العملية الرئيسية. قد يقتل الشخص الذي يجري الاختبار أي عمليات ضالة. يجب ألا تسرب الاختبارات العمليات بهذه الطريقة.

تجزئة الاختبار

يمكن أيضًا موازاة الاختبارات من خلال إجراء الاختبار. راجِع --test_sharding_strategy وshard_count لتفعيل التقسيم إلى أجزاء تجريبية. عند تفعيل التجزئة، يتم تشغيل تشغيل الاختبار مرة واحدة لكل جزء. متغير البيئة TEST_TOTAL_SHARDS هو عدد الأجزاء، وTEST_SHARD_INDEX هو فهرس الجزء، الذي يبدأ من 0. يستخدم المتسابقون هذه المعلومات لاختيار الاختبارات التي يريدون تنفيذها، على سبيل المثال، باستخدام استراتيجية ترتيب دوري. لا يتيح بعض مُشغّلي الاختبار إجراء عمليات التجزئة. في حال كان هناك مستخدم يشغّل عملية التجزئة، عليه إنشاء أو تعديل تاريخ آخر تعديل للملف المحدَّد في TEST_SHARD_STATUS_FILE. وبخلاف ذلك، يفترض Bazel أنّه لا يوفّر عمليات التقسيم ولن يشغّل ألعاب الركض الإضافية.

الشروط الأولية

عند تنفيذ الاختبار، يجب أن يحدد إجراء الاختبار شروطًا أولية محدّدة.

يجب أن يستدعي المستخدم إجراء كل اختبار مع المسار إلى الملف التنفيذي للاختبار في argv[0]. يجب أن يكون هذا المسار نسبيًا وضمن الدليل الحالي لـ test' (وهو ضمن شجرة الملفات، انظر أدناه). يجب على المستخدم الذي يجري الاختبار عدم تمرير أي وسيطات أخرى إلى الاختبار ما لم يطلبه المستخدم صراحةً.

تتألف كتلة البيئة الأولية على النحو التالي:

متغير	القيمة	الحالة
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	المسار المطلق لملف خاص في دليل قابل للكتابة (يُستخدم لكتابة سجل Logtopltter Protobuffer)	إجراء اختياري
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	الموقع الذي يجب أن تكتب إجراءات الاختبار فيه ملف إخراج 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	غير محدودة، أو 2044 كيلوبايت <= rlim <= 8192 كيلوبايت

إنّ الأوقات الأوليّة للعملية (التي يعرضها times()) ويستخدمها الموارد (التي يعرضها getrusage()) غير محدّدة.

تكون سياسة الجدولة الأولية والأولوية غير محددتَين.

دور النظام المضيف

بالإضافة إلى جوانب سياق المستخدم تحت التحكّم المباشر في الشخص الذي يجري الاختبار، يجب أن يستوفي نظام التشغيل الذي يتم تنفيذ الاختبارات عليه خصائص معيّنة لإجراء اختبار ليكون صالحًا.

نظام الملفات

وقد يكون الدليل الجذري الذي استخدمه أحد الاختبارات هو الدليل الجذري الحقيقي أو لا.

سيتم تثبيت /proc.

يجب استخدام كل أدوات الإصدار في المسارات المطلقة تحت /usr التي يستخدمها التثبيت على الجهاز.

قد لا تتوفر المسارات التي تبدأ بـ /home. ويجب ألا تصل الاختبارات إلى أي من هذه المسارات.

يجب أن يكون /tmp قابلاً للكتابة، ولكن يجب أن تتجنّب الاختبارات استخدام هذه المسارات.

يجب ألا تفترض الاختبارات أن أي مسار ثابت متاح للاستخدام الحصري.

يجب ألا تفترض الاختبارات أن أوقات التشغيل مفعّلة لأي نظام ملفات تم تثبيته.

المستخدمون والمجموعات

يجب أن يتوفّر جذر المستخدم، ولا يتوفر أي مستخدم، أو ملفاختبار. يجب أن يتوفّر جذر المجموعات ولا يوجد أحد وشارك.

يجب تنفيذ الاختبارات كمستخدم غير جذري. يجب أن تكون أرقام تعريف المستخدمين الفعلية والفعّالة متساوية، وبالمثل بالنسبة إلى أرقام تعريف المجموعات. بالإضافة إلى ذلك، لا يتم تحديد رقم تعريف المستخدم الحالي ورقم تعريف المجموعة واسم المستخدم واسم المجموعة. مجموعة معرّفات المجموعات التكميلية غير محدّدة.

يجب أن يحتوي رقم تعريف المستخدم الحالي ومعرّف المجموعة على أسماء مقابلة يمكن استردادها باستخدام getpwuid() وgetgrgid(). وقد لا ينطبق الأمر نفسه على معرّفات المجموعة التكميلية.

يجب أن يكون لدى المستخدم الحالي دليل رئيسي. قد لا يكون قابلاً للكتابة. ويجب ألا تحاول الاختبارات الكتابة إليها.

اتصال بالشبكات

اسم المضيف غير محدد. قد يحتوي على نقطة أو لا يحتوي عليها. يجب أن يؤدي حلّ اسم المضيف إلى منح عنوان IP للمضيف الحالي. يجب حلّ مشكلة اسم المضيف المُقتطَع بعد النقطة الأولى أيضًا. يجب حلّ المضيف المحلي لاسم المضيف.

مراجع أخرى

يتم منح الاختبارات وحدة معالجة مركزية واحدة على الأقل. وهناك خيارات أخرى قد تكون متاحة، ولكن لا يمكن ضمان ذلك. لم يتم تحديد جوانب الأداء الأخرى لهذا النواة. ويمكنك زيادة الحجز إلى عدد أكبر من وحدات معالجة وحدة المعالجة المركزية (CPU) عن طريق إضافة العلامة "cpu:n" (حيث يكون رقم n رقمًا موجبًا) إلى قاعدة اختبار. إذا كان الجهاز مزوّدًا بمعالج وحدة معالجة مركزية (CPU) أقل إجماليًا من العدد المطلوب، سيواصل Bazel إجراء الاختبار. إذا كان الاختبار يستخدم التقسيم، سيحتفظ كل جزء فردي بعدد وحدات المعالجة المركزية (CPU) المحدّدة هنا.

قد تؤدي الاختبارات إلى إنشاء عمليات فرعية، وليس معالجة مجموعات أو جلسات.

هناك حدّ أقصى لعدد ملفات الإدخال التي يمكن أن يستخدمها الاختبار. هذا الحدّ عرضة للتغيير، ولكنه حاليًا في نطاق عشرات الآلاف من الإدخالات.

وقت وتاريخ

ولا يتم تحديد الوقت والتاريخ الحاليَين. لم يتم تحديد المنطقة الزمنية للنظام.

وقد يكون X Windows متاحًا أو غير متوفر. يجب أن تبدأ الاختبارات التي تحتاج إلى خادم X Xvfb.

اختبار التفاعل مع نظام الملفات

تشير جميع مسارات الملفات المحدّدة في متغيّرات بيئة الاختبار إلى مكان ما على نظام الملفات المحلي، ما لم يُذكر خلاف ذلك.

يجب ألا تنشئ الاختبارات ملفات إلا ضمن الأدلة المحدّدة في $TEST_TMPDIR و$TEST_UNDECLARED_OUTPUTS_DIR (في حال ضبطها).

ستكون هذه الأدلة فارغة في البداية.

ويجب ألا تحاول الاختبارات إزالة هذه الأدلة أو تغييرها أو تغييرها بأي طريقة أخرى.

قد تكون هذه الأدلة روابط رمزية.

لم يتم تحديد نوع نظام الملفات لـ $TEST_TMPDIR/..

وقد تكتب الاختبارات أيضًا ملفات .part على $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR لإضافة تعليقات توضيحية إلى ملفات المخرجات غير المعلَنة.

في حالات نادرة، قد يتم فرض اختبار لإنشاء ملفات في /tmp. على سبيل المثال، عادةً ما تتطلب حدود طول المسار في مقابس نطاق Unix إنشاء المقبس ضمن /tmp. لن يتمكّن Bazel من تتبُّع هذه الملفات، لأنّ الاختبار نفسه يجب أن يكون دقيقًا، واستخدِم المسارات الفريدة لتجنُّب التصادُم مع الاختبارات الأخرى والعمليات غير التجريبية في الوقت نفسه، وتنظيف الملفات التي ينشئها في /tmp.

بعض أُطر عمل الاختبار الشائعة، مثل JUnit4 TemporaryFolder أو Go TempDir، تستخدم طرقًا خاصة لإنشاء دليل مؤقت ضمن /tmp. تتضمّن إطارات العمل التجريبية هذه وظائف تعمل على تنظيم الملفات في /tmp، لذا يمكنك استخدامها على الرغم من إنشائها لملفات خارج TEST_TMPDIR.

يجب أن تتيح الاختبارات الوصول إلى البيانات من خلال الآلية runfiles، أو أجزاء أخرى من بيئة التنفيذ المصمّمة خصيصًا لإتاحة ملفات الإدخال.

يجب ألا تصل الاختبارات إلى مخرجات أخرى لنظام الإصدار في المسارات التي يتم استنتاجها من موقع موقعها الجغرافي القابل للتنفيذ.

ولا يتم تحديد ما إذا كانت شجرة الملفات التي يتم تشغيلها تحتوي على ملفات عادية أو روابط رمزية أو مزيج منهما. قد يحتوي العرض التدرّجي للملفات على روابط رمزية للأدلة. يجب أن تتجنّب الاختبارات استخدام مسارات تحتوي على مكوّنات .. ضمن شجرة التشغيل.

ويجب أن يكون أي دليل أو ملف أو رابط رمزي ضمن شجرة الملفات التي يتم تشغيلها (بما في ذلك المسارات التي تتجاوز الروابط الرمزية) قابلاً للكتابة. (يجب أن يكون دليل العمل الأولي غير قابل للكتابة.) يجب ألا تفترض الاختبارات أن أي جزء من الملفات القابلة للتنفيذ أو قابل للكتابة، أو مملوك من المستخدم الحالي (على سبيل المثال، قد يتعذّر إتمام chmod وchgrp).

يجب ألا يتغيّر عرض شجرة الملفات التي يتم تشغيلها (بما في ذلك المسارات التي تتجاوز الروابط الرمزية) أثناء تنفيذ الاختبار. يجب ألا تتغير الأدلة الرئيسية وعمليات تثبيت نظام الملفات بأي شكل، ما يؤثر في نتيجة تحديد مسار ضمن شجرة الملفات.

من أجل رصد الخروج المبكر، يمكن أن ينشئ الاختبار ملفًا على المسار الذي يحدده TEST_PREMATURE_EXIT_FILE عند البدء وإزالته عند الخروج. إذا رأى Bazel الملف عند انتهاء الاختبار، سيفترض أنّه تم الخروج من الاختبار قبل الأوان ووضع علامة عليه على أنه تعذّر.

اصطلاحات وضع العلامات

تحمل بعض العلامات في قواعد الاختبار معنى خاصًا. يمكنك أيضًا الاطّلاع على موسّع Bazel Build الموسوعة على السمة tags.

العلامة	المعنى
exclusive	عدم إجراء أي اختبار آخر في الوقت نفسه
external	اختبار يعتمد على الاعتماد الخارجي: إيقاف التخزين المؤقت للاختبار
large	اصطلاح test_suite، مجموعة من الاختبارات الكبيرة
manual *	لا تُدرِج هدف الاختبار في أنماط أهداف أحرف البدل، مثل :... أو :* أو :all.
medium	اتفاقية test_suite، مجموعة من الاختبارات المتوسطة
small	طريقة استخدام test_suite، مجموعة من الاختبارات الصغيرة
smoke	اصطلاح test_suite، وهذا يعني أنه يجب تشغيله قبل تنفيذ التغييرات على الرمز في نظام التحكّم في الإصدارات

ملفات التشغيل

في ما يلي، نفترض أنّ هناك قاعدة *_binary() باسم //foo/bar:unittest، مع اعتمادية وقت التشغيل على القاعدة المُسمّاة //deps/server:server.

الموقع الجغرافي

الدليل runfiles لهدف //foo/bar:unittest هو الدليل$(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. ويُشار إلى هذا المسار باسم runfiles_dir.

المهام التابعة

يتم تعريف دليل runfiles كاعتمادية على وقت التجميع للقاعدة *_binary(). يعتمد دليل تنفيذ الملفات نفسه على مجموعة ملفات BUILD التي تؤثر في قاعدة *_binary() أو أي من العناصر التابعة لوقت التجميع أو وقت التشغيل. لا يؤثّر تعديل ملفات المصدر في بنية دليل تنفيذ الملفات، وبالتالي لا يؤدي إلى أي إعادة إنشاء.

المحتويات

يحتوي دليل runfiles على ما يلي:

• روابط إلى تبعيات وقت التشغيل: يتم تمثيل كل من مخرجات الملفات وقاعدة الأوامر التي تعتمد على وقت التشغيل للقاعدة *_binary() من خلال رمز رمزي واحد في دليل ملفات قيد التشغيل. واسم الرابط الرمزي هو $(WORKSPACE)/package_name/rule_name. على سبيل المثال، سيُطلق اسم الرمز المميز للخادم $(WORKSPACE)/deps/server/server على المسار الكامل، وسيكون المسار $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. وجهة الرابط الرمزي هي ProductionFileName() من ملف الإخراج أو CommandRule (القاعدة)، ويتم التعبير عنها كمسار مطلق. وبالتالي، قد تكون وجهة الرمز المميز $(WORKSPACE)/linux-dbg/deps/server/42/server.
• روابط إلى الملفات التي يتم تشغيلها فرعيًا: بالنسبة إلى كل *_binary() Z التي تعتمد على وقت التشغيل *_binary() C، هناك رابط ثانٍ في دليل runfiles الخاص بـ C إلى ملفات التشغيل Z. واسم الرابط الرمزي هو $(WORKSPACE)/package_name/rule_name.runfiles. الهدف من رابط الرمز هو دليل runfiles. على سبيل المثال، تتشارك جميع البرامج الفرعية في دليل تنفيذ ملفات شائع.