สารานุกรมการทดสอบ

ข้อกำหนดที่ครอบคลุมของสภาพแวดล้อมการดำเนินการทดสอบ

ฉากหลัง

ภาษา Bazel BUILD มีกฎที่ใช้กำหนดโปรแกรมทดสอบอัตโนมัติในหลายภาษาได้

การทดสอบจะดำเนินการโดยใช้ bazel test

นอกจากนี้ ผู้ใช้ยังเรียกใช้ไบนารีทดสอบได้โดยตรงด้วย เราอนุญาตให้ทำได้แต่ไม่แนะนำ เนื่องจากการเรียกใช้ดังกล่าวจะไม่เป็นไปตามคำสั่งที่อธิบายไว้ด้านล่าง

การทดสอบควรเป็นแบบปิด นั่นคือควรเข้าถึงเฉพาะทรัพยากรที่ประกาศการอ้างอิงไว้เท่านั้น หากการทดสอบไม่เป็นไปตามข้อกำหนดของ Hermetic การทดสอบจะไม่ให้ผลลัพธ์ที่ทำซ้ำได้ในอดีต ซึ่งอาจเป็น ปัญหาสำคัญในการค้นหาต้นเหตุ (การพิจารณาว่าการเปลี่ยนแปลงใดทำให้การทดสอบล้มเหลว) การตรวจสอบการตรวจสอบการเผยแพร่ และการแยกทรัพยากรของการทดสอบ (เฟรมเวิร์กการทดสอบอัตโนมัติ ไม่ควร DDOS เซิร์ฟเวอร์เนื่องจากการทดสอบบางอย่างอาจสื่อสารกับเซิร์ฟเวอร์)

วัตถุประสงค์

เป้าหมายของหน้านี้คือการสร้างสภาพแวดล้อมรันไทม์อย่างเป็นทางการและลักษณะการทำงานที่คาดไว้ของการทดสอบ Bazel นอกจากนี้ยังกำหนดข้อกำหนดสำหรับโปรแกรมเรียกใช้การทดสอบและระบบบิลด์ด้วย

ข้อกำหนดสภาพแวดล้อมการทดสอบช่วยให้ผู้เขียนการทดสอบหลีกเลี่ยงการพึ่งพาพฤติกรรมที่ไม่ได้ระบุ และช่วยให้โครงสร้างพื้นฐานการทดสอบมีอิสระมากขึ้นในการเปลี่ยนแปลงการติดตั้งใช้งาน ข้อกำหนดนี้จะอุดช่องโหว่บางอย่างที่ ปัจจุบันทำให้การทดสอบจำนวนมากผ่านได้แม้ว่าจะไม่เป็นแบบเฮอร์เมติก แบบดีเทอร์มินิสติก และแบบรีเอนแทรนต์อย่างเหมาะสมก็ตาม

หน้านี้มีจุดประสงค์เพื่อเป็นทั้งบรรทัดฐานและแหล่งข้อมูลที่เชื่อถือได้ หากข้อมูลจำเพาะนี้และลักษณะการทำงานที่ใช้ของโปรแกรมเรียกใช้การทดสอบไม่ตรงกัน ข้อมูลจำเพาะจะมีความสำคัญสูงกว่า

ข้อกำหนดที่เสนอ

คำสำคัญ "ต้อง" "ห้าม" "จำเป็น" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" จะตีความตามที่อธิบายไว้ใน IETF RFC 2119

วัตถุประสงค์ของการทดสอบ

จุดประสงค์ของการทดสอบ Bazel คือการยืนยันคุณสมบัติบางอย่างของไฟล์ต้นฉบับ ที่เช็คอินในที่เก็บ (ในหน้านี้ "ไฟล์ต้นฉบับ" รวมถึงข้อมูลทดสอบ เอาต์พุตที่ถูกต้อง และสิ่งอื่นๆ ที่เก็บไว้ภายใต้การควบคุมเวอร์ชัน) ผู้ใช้เขียนการทดสอบเพื่อยืนยันตัวแปรที่ไม่เปลี่ยนแปลงซึ่งคาดว่าจะยังคงอยู่ ผู้ใช้รายอื่น เรียกใช้การทดสอบในภายหลังเพื่อตรวจสอบว่ามีการละเมิดค่าคงที่หรือไม่ หากการทดสอบขึ้นอยู่กับตัวแปรอื่นๆ นอกเหนือจากไฟล์ต้นฉบับ (ไม่ใช่แบบปิด) ค่าของการทดสอบจะลดลง เนื่องจากผู้ใช้ในภายหลังไม่สามารถมั่นใจได้ว่าการเปลี่ยนแปลงของตนเองเป็นสาเหตุที่ทำให้การทดสอบไม่ผ่าน

ดังนั้น ผลลัพธ์ของการทดสอบจึงต้องขึ้นอยู่กับสิ่งต่อไปนี้เท่านั้น

• ไฟล์ต้นฉบับที่การทดสอบมีการประกาศการอ้างอิง
• ผลิตภัณฑ์ของระบบบิลด์ที่การทดสอบมีการประกาศการขึ้นต่อกัน
• ทรัพยากรที่ Test Runner รับประกันว่าจะมีลักษณะการทำงานคงที่

ปัจจุบันระบบยังไม่ได้บังคับใช้พฤติกรรมดังกล่าว อย่างไรก็ตาม โปรแกรมเรียกใช้การทดสอบขอสงวนสิทธิ์ ในการเพิ่มการบังคับใช้ดังกล่าวในอนาคต

บทบาทของระบบบิลด์

กฎการทดสอบจะคล้ายกับกฎไบนารีตรงที่แต่ละกฎต้องสร้างโปรแกรมที่เรียกใช้ได้ สำหรับบางภาษา โปรแกรมนี้เป็นโปรแกรม Stub ที่รวม Harness เฉพาะภาษาเข้ากับโค้ดทดสอบ กฎการทดสอบต้องสร้างเอาต์พุตอื่นๆ ด้วย นอกเหนือจากไฟล์ปฏิบัติการทดสอบหลักแล้ว Test Runner จะต้องมีไฟล์ Manifest ของrunfiles ไฟล์อินพุตที่ควรพร้อมใช้งาน สำหรับการทดสอบที่รันไทม์ และอาจต้องมีข้อมูลเกี่ยวกับประเภท ขนาด และ แท็กของการทดสอบ

ระบบบิลด์อาจใช้ไฟล์ที่เรียกใช้เพื่อส่งโค้ดและข้อมูล (อาจใช้เป็นวิธีเพิ่มประสิทธิภาพเพื่อลดขนาดไบนารีของการทดสอบแต่ละรายการโดยการแชร์ไฟล์ในการทดสอบต่างๆ เช่น ผ่านการใช้การลิงก์แบบไดนามิก) ระบบบิลด์ ควรตรวจสอบว่าไฟล์ที่สร้างขึ้นโหลดไฟล์เหล่านี้ผ่านอิมเมจไฟล์ที่เรียกใช้ ซึ่งจัดทำโดยโปรแกรมเรียกใช้การทดสอบ แทนที่จะใช้การอ้างอิงที่ฮาร์ดโค้ดไปยังตำแหน่งที่แน่นอน ในซอร์สหรือทรีเอาต์พุต

บทบาทของโปรแกรมเรียกใช้การทดสอบ

จากมุมมองของโปรแกรมเรียกใช้การทดสอบ การทดสอบแต่ละรายการคือโปรแกรมที่เรียกใช้ได้ด้วย execve() อาจมีวิธีอื่นๆ ในการเรียกใช้การทดสอบ เช่น IDE อาจอนุญาตให้เรียกใช้การทดสอบ Java ในกระบวนการ อย่างไรก็ตาม ผลลัพธ์ ของการทดสอบในฐานะกระบวนการแบบสแตนด์อโลนถือเป็นผลลัพธ์ที่เชื่อถือได้ หาก กระบวนการทดสอบทำงานจนเสร็จสมบูรณ์และสิ้นสุดตามปกติโดยมีรหัสออกเป็น 0 แสดงว่าการทดสอบผ่าน ผลลัพธ์อื่นๆ จะถือว่าการทดสอบล้มเหลว โดยเฉพาะอย่างยิ่ง การเขียนสตริง PASS หรือ FAIL ไปยัง stdout จะไม่มีผลต่อตัวเรียกใช้การทดสอบ

หากการทดสอบใช้เวลานานเกินไป เกินขีดจำกัดของทรัพยากรบางอย่าง หรือโปรแกรมเรียกใช้การทดสอบตรวจพบพฤติกรรมที่ไม่อนุญาต ระบบอาจเลือกที่จะหยุดการทดสอบและถือว่าการเรียกใช้ล้มเหลว โปรแกรมทดสอบต้องไม่รายงานว่าการทดสอบผ่านหลังจาก ส่งสัญญาณไปยังกระบวนการทดสอบหรือกระบวนการย่อยใดๆ

เป้าหมายการทดสอบทั้งหมด (ไม่ใช่แต่ละวิธีหรือการทดสอบ) จะมีเวลาจำกัดในการทำงานจนเสร็จสมบูรณ์ ขีดจำกัดเวลาสำหรับการทดสอบจะอิงตามแอตทริบิวต์ timeout ตามตารางต่อไปนี้

เวลานอก	ขีดจำกัดเวลา (วินาที)
วิดีโอสั้น	60
ปานกลาง	300
ยาว	900
นิรันดร	3600

การทดสอบที่ไม่ได้ระบุการหมดเวลาอย่างชัดเจนจะมีค่าที่กำหนดโดยนัยตามsizeของการทดสอบดังนี้

ขนาด	ป้ายกำกับหมดเวลาโดยนัย
เล็ก	วิดีโอสั้น
ปานกลาง	ปานกลาง
ใหญ่	ยาว
ใหญ่โต	นิรันดร

การทดสอบ "ขนาดใหญ่" ที่ไม่มีการตั้งค่าการหมดเวลาอย่างชัดเจนจะได้รับเวลา 900 วินาทีในการเรียกใช้ การทดสอบ "ปานกลาง" ที่มีระยะหมดเวลาเป็น "สั้น" จะมีระยะเวลา 60 วินาที

size จะกำหนดการใช้งานสูงสุดโดยประมาณของ ทรัพยากรอื่นๆ (เช่น RAM) เมื่อเรียกใช้การทดสอบในเครื่องด้วย ตามที่อธิบายไว้ในคำจำกัดความทั่วไป ซึ่งแตกต่างจาก timeout

การผสมป้ายกำกับ size และ timeout ทั้งหมดเป็นไปตามกฎหมาย ดังนั้นการทดสอบ "นานมาก" อาจประกาศว่ามีระยะหมดเวลาเป็น "สั้น" ซึ่งคาดว่ามันจะทำสิ่ง ที่น่ากลัวมากๆ ได้อย่างรวดเร็ว

การทดสอบอาจแสดงผลอย่างรวดเร็วโดยไม่คำนึงถึงการหมดเวลา การทดสอบจะไม่ถูกลงโทษ เนื่องจากตั้งค่าการหมดเวลาไว้สูงเกินไป แม้ว่าอาจมีการออกคำเตือนก็ตาม โดยทั่วไปคุณควร ตั้งค่าการหมดเวลาให้ต่ำที่สุดเท่าที่จะทำได้โดยไม่ทำให้เกิดความไม่เสถียร

คุณสามารถลบล้างการหมดเวลาทดสอบได้ด้วยแฟล็ก --test_timeout bazel เมื่อ เรียกใช้ด้วยตนเองภายใต้เงื่อนไขที่ทราบว่าช้า ค่า --test_timeout มีหน่วยเป็นวินาที เช่น --test_timeout=120 จะตั้งค่าการหมดเวลาทดสอบเป็น 2 นาที

นอกจากนี้ ยังมีขอบเขตล่างที่แนะนำสำหรับการหมดเวลาทดสอบดังนี้

เวลานอก	เวลาขั้นต่ำ (วินาที)
วิดีโอสั้น	0
ปานกลาง	30
ยาว	300
นิรันดร	900

เช่น หากการทดสอบ "ปานกลาง" เสร็จสมบูรณ์ใน 5.5 วินาที ให้ลองตั้งค่า timeout = "short" หรือ size = "small" การใช้ตัวเลือกบรรทัดคำสั่ง --test_verbose_timeout_warnings bazel จะแสดงการทดสอบที่มีขนาดที่ระบุใหญ่เกินไป

ขนาดการทดสอบและระยะหมดเวลาจะระบุไว้ในไฟล์ BUILD ตามข้อกำหนดที่นี่ หากไม่ได้ระบุ ขนาดของการทดสอบจะมีค่าเริ่มต้นเป็น "ปานกลาง"

หากกระบวนการหลักของการทดสอบสิ้นสุดลง แต่กระบวนการย่อยบางส่วนยังคงทำงานอยู่ โปรแกรมเรียกใช้การทดสอบควรพิจารณาว่าการทดสอบเสร็จสมบูรณ์แล้ว และนับเป็นการทดสอบที่สำเร็จหรือ ล้มเหลวตามรหัสการออกที่สังเกตได้จากกระบวนการหลัก โปรแกรมเรียกใช้การทดสอบ อาจปิดกระบวนการที่หลงเหลืออยู่ การทดสอบไม่ควรทำให้กระบวนการรั่วไหลในลักษณะนี้

การแบ่งพาร์ติชันการทดสอบ

คุณสามารถทำการทดสอบแบบขนานได้ผ่านการแบ่งการทดสอบ ดู--test_sharding_strategy และ shard_count เพื่อ เปิดใช้การแบ่งพาร์ติชันการทดสอบ เมื่อเปิดใช้การแบ่งพาร์ติชัน ระบบจะเปิดใช้โปรแกรมเรียกใช้การทดสอบ 1 ครั้ง ต่อพาร์ติชัน ตัวแปรสภาพแวดล้อม TEST_TOTAL_SHARDS คือจำนวน Shard และ TEST_SHARD_INDEX คือ ดัชนี Shard โดยเริ่มต้นที่ 0 Runner ใช้ข้อมูลนี้เพื่อเลือกการทดสอบที่จะเรียกใช้ เช่น ใช้กลยุทธ์แบบ Round Robin โปรแกรมเรียกใช้การทดสอบบางรายการไม่รองรับ การแบ่งพาร์ติชัน หากโปรแกรมเรียกใช้รองรับการแยกส่วน จะต้องสร้างหรืออัปเดตวันที่แก้ไขล่าสุดของไฟล์ที่ระบุโดย TEST_SHARD_STATUS_FILE ไม่เช่นนั้น หากเปิดใช้ --incompatible_check_sharding_support Bazel จะทดสอบไม่สำเร็จหากมีการแยกส่วน

เงื่อนไขเริ่มต้น

เมื่อทำการทดสอบ โปรแกรมเรียกใช้การทดสอบต้องสร้างเงื่อนไขเริ่มต้นบางอย่าง

โปรแกรมเรียกใช้การทดสอบต้องเรียกใช้การทดสอบแต่ละรายการด้วยเส้นทางไปยังไฟล์ปฏิบัติการทดสอบใน 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	เส้นทางแบบสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ควรใช้ไฟล์นี้ เพื่อรายงานความล้มเหลวที่เกิดจากโครงสร้างพื้นฐานการทดสอบเท่านั้น ไม่ใช่กลไกทั่วไปสำหรับการรายงานความล้มเหลวที่ไม่เสถียร ของการทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานในการทดสอบหมายถึงระบบ หรือไลบรารีที่ไม่ได้เฉพาะเจาะจงสำหรับการทดสอบ แต่สามารถทำให้การทดสอบล้มเหลวได้ เนื่องจากทำงานผิดปกติ บรรทัดแรกคือชื่อของคอมโพเนนต์โครงสร้างพื้นฐานการทดสอบ ที่ทำให้เกิดความล้มเหลว ส่วนบรรทัดที่ 2 คือคำอธิบายที่มนุษย์อ่านได้ ของความล้มเหลว ระบบจะไม่สนใจบรรทัดเพิ่มเติม)	ไม่บังคับ
TEST_LOGSPLITTER_OUTPUT_FILE	เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้เพื่อเขียน บันทึก Logsplitter 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	ดัชนีของ Shard หากใช้ sharding	ไม่บังคับ
TEST_SHARD_STATUS_FILE	เส้นทางไปยังไฟล์ที่จะแตะเพื่อระบุการรองรับ sharding	ไม่บังคับ
TEST_SRCDIR	เส้นทางสัมบูรณ์ไปยังฐานของทรีไฟล์ที่เรียกใช้	ต้องระบุ
TEST_TOTAL_SHARDS	total shard count, หากใช้ sharding	ไม่บังคับ
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	ตำแหน่งที่การดำเนินการทดสอบควรเขียนไฟล์เอาต์พุต XML ของผลการทดสอบ มิฉะนั้น Bazel จะสร้างไฟล์เอาต์พุต XML เริ่มต้นที่รวมบันทึกการทดสอบ เป็นส่วนหนึ่งของการดำเนินการทดสอบ สคีมา XML อิงตาม สคีมาผลการทดสอบ JUnit	ไม่บังคับ
BAZEL_TEST	ระบุว่า bazel test เป็นผู้ขับเคลื่อนไฟล์ปฏิบัติการทดสอบ	ต้องระบุ

สภาพแวดล้อมอาจมีรายการเพิ่มเติม การทดสอบไม่ควรขึ้นอยู่กับ การมีอยู่ การไม่มีอยู่ หรือค่าของตัวแปรสภาพแวดล้อมที่ไม่ได้ระบุไว้ข้างต้น

ไดเรกทอรีการทำงานเริ่มต้นต้องเป็น $TEST_SRCDIR/$TEST_WORKSPACE

รหัสกระบวนการปัจจุบัน รหัสกลุ่มกระบวนการ รหัสเซสชัน และรหัสกระบวนการหลักไม่ได้ระบุ กระบวนการอาจเป็นหรือไม่เป็นผู้นำกลุ่มกระบวนการหรือผู้นำเซสชันก็ได้ กระบวนการนี้อาจมีหรือไม่มีเทอร์มินัลควบคุมก็ได้ กระบวนการอาจมีกระบวนการย่อยที่ทำงานอยู่หรือยังไม่ได้เก็บเกี่ยวอย่างน้อย 1 รายการ กระบวนการไม่ควรมีหลายเธรดเมื่อโค้ดทดสอบได้รับการควบคุม

ต้องเปิดตัวอธิบายไฟล์ 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	ไม่จำกัด หรือ 2044KB <= rlim <= 8192KB

เวลาในการประมวลผลเริ่มต้น (ตามที่ times() แสดง) และการใช้ทรัพยากร (ตามที่ getrusage() แสดง) ไม่ได้ระบุไว้

ไม่ได้ระบุนโยบายการจัดตารางเวลาและลำดับความสำคัญเริ่มต้น

บทบาทของระบบโฮสต์

นอกเหนือจากแง่มุมของบริบทผู้ใช้ภายใต้การควบคุมโดยตรงของโปรแกรมเรียกใช้การทดสอบแล้ว ระบบปฏิบัติการที่ใช้เรียกใช้การทดสอบต้องมีคุณสมบัติบางอย่างเพื่อให้การทดสอบถูกต้อง

ระบบไฟล์

ไดเรกทอรีรากที่การทดสอบสังเกตอาจเป็นหรือไม่เป็นไดเรกทอรีรากจริงก็ได้

/proc จะต้องติดตั้ง

เครื่องมือบิลด์ทั้งหมดต้องอยู่ที่เส้นทางสมบูรณ์ภายใต้ /usr ที่ใช้โดยการติดตั้งในเครื่อง

เส้นทางที่ขึ้นต้นด้วย /home อาจไม่พร้อมใช้งาน การทดสอบไม่ควรเข้าถึงเส้นทางดังกล่าว

/tmp ต้องเขียนได้ แต่การทดสอบควรหลีกเลี่ยงการใช้เส้นทางเหล่านี้

การทดสอบต้องไม่ถือว่ามีเส้นทางคงที่ใดๆ สำหรับการใช้งานเฉพาะของตนเอง

การทดสอบต้องไม่ถือว่ามีการเปิดใช้ atime สำหรับระบบไฟล์ที่ติดตั้ง

ผู้ใช้และกลุ่ม

ต้องมีผู้ใช้ root, nobody และ unittest ต้องมีกลุ่ม root, nobody และ eng

ต้องเรียกใช้การทดสอบในฐานะผู้ใช้ที่ไม่ใช่รูท รหัสผู้ใช้จริงและรหัสผู้ใช้ที่มีผลบังคับใช้ต้อง เท่ากัน เช่นเดียวกับรหัสกลุ่ม นอกจากนี้ ระบบจะไม่ระบุรหัสผู้ใช้ รหัสกลุ่ม ชื่อผู้ใช้ และชื่อกลุ่มปัจจุบัน ไม่ได้ระบุชุดรหัสกลุ่มเสริม

รหัสผู้ใช้และรหัสกลุ่มปัจจุบันต้องมีชื่อที่สอดคล้องกันซึ่งสามารถเรียกข้อมูลได้ด้วย getpwuid() และ getgrgid() แต่สำหรับรหัสกลุ่มเสริมอาจไม่เป็นเช่นนั้น

ผู้ใช้ปัจจุบันต้องมีไดเรกทอรีหลัก อาจเขียนไม่ได้ การทดสอบต้อง ไม่พยายามเขียนไปยังไฟล์นี้

เครือข่าย

ไม่ได้ระบุชื่อโฮสต์ โดยอาจมีหรือไม่มีจุดก็ได้ การแก้ปัญหาชื่อโฮสต์ต้องให้ที่อยู่ IP ของโฮสต์ปัจจุบัน การแก้ไขชื่อโฮสต์ที่ตัด หลังจุดแรกต้องใช้งานได้ด้วย ชื่อโฮสต์ localhost ต้องได้รับการแก้ไข

แหล่งข้อมูลอื่นๆ

การทดสอบจะได้รับ CPU Core อย่างน้อย 1 Core ส่วนวิธีอื่นๆ อาจใช้ได้ แต่ไม่รับประกัน ไม่ได้ระบุประสิทธิภาพด้านอื่นๆ ของแกนหลักนี้ คุณเพิ่มการจองเป็นจำนวนคอร์ CPU ที่สูงขึ้นได้โดยเพิ่มแท็ก "cpu:n" (โดยที่ n เป็นจำนวนบวก) ลงในกฎการทดสอบ หากเครื่องมีจำนวนคอร์ CPU ทั้งหมดน้อยกว่าที่ขอ Bazel จะยังคงเรียกใช้การทดสอบ หากการทดสอบใช้ การแบ่งส่วน แต่ละส่วนจะจองจำนวนแกน 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 หรือ Go TempDir มี วิธีสร้างไดเรกทอรีชั่วคราวภายใต้ /tmp เป็นของตัวเอง เฟรมเวิร์กการทดสอบเหล่านี้ มีฟังก์ชันการทำงานที่ล้างไฟล์ใน /tmp คุณจึงใช้ เฟรมเวิร์กเหล่านี้ได้แม้ว่าจะสร้างไฟล์ภายนอก TEST_TMPDIR ก็ตาม

การทดสอบต้องเข้าถึงอินพุตผ่านกลไก runfiles หรือส่วนอื่นๆ ของ สภาพแวดล้อมการดำเนินการที่มีวัตถุประสงค์เฉพาะเพื่อทำให้ไฟล์อินพุต พร้อมใช้งาน

การทดสอบต้องไม่เข้าถึงเอาต์พุตอื่นๆ ของระบบบิลด์ในเส้นทางที่อนุมานจาก ตำแหน่งของไฟล์ที่เรียกใช้งานได้ของตัวเอง

ไม่ได้ระบุว่าทรีไฟล์ที่เรียกใช้มีไฟล์ปกติ ลิงก์สัญลักษณ์ หรือทั้ง 2 อย่าง ทรีของไฟล์ที่เรียกใช้ได้อาจมีลิงก์สัญลักษณ์ไปยังไดเรกทอรี การทดสอบควรหลีกเลี่ยงการใช้เส้นทางที่มีคอมโพเนนต์ .. ภายในทรีไฟล์ที่เรียกใช้

ไม่ควรเขียนไดเรกทอรี ไฟล์ หรือลิงก์สัญลักษณ์ภายในทรีของไฟล์ที่เรียกใช้ (รวมถึงเส้นทางที่ข้ามลิงก์สัญลักษณ์) (ดังนั้นจึงไม่ควรเขียนทับไดเรกทอรีการทำงานเริ่มต้น) การทดสอบต้องไม่ถือว่าส่วนใดส่วนหนึ่งของ runfiles สามารถเขียนได้ หรือเป็นของผู้ใช้ปัจจุบัน (เช่น chmod และ chgrp อาจ ล้มเหลว)

โครงสร้างไฟล์ที่เรียกใช้ (รวมถึงเส้นทางที่ข้ามลิงก์สัญลักษณ์) ต้องไม่เปลี่ยนแปลง ในระหว่างการทดสอบ ไดเรกทอรีหลักและการติดตั้งระบบไฟล์ต้องไม่เปลี่ยนแปลง ในลักษณะใดก็ตามที่ส่งผลต่อผลลัพธ์ของการแก้ไขเส้นทางภายในทรีของไฟล์ที่เรียกใช้

การทดสอบอาจสร้างไฟล์ในเส้นทางที่ระบุโดย TEST_PREMATURE_EXIT_FILE เมื่อเริ่มต้นและนำออกเมื่อสิ้นสุด เพื่อตรวจจับการออกก่อนเวลา หาก Bazel เห็นไฟล์ เมื่อการทดสอบเสร็จสิ้น Bazel จะถือว่าการทดสอบออกก่อนเวลาอันควรและ ทําเครื่องหมายว่าไม่สําเร็จ

แพลตฟอร์มการดำเนินการ

แพลตฟอร์มการดำเนินการสำหรับการดำเนินการทดสอบจะกำหนดผ่านการแก้ปัญหา Toolchain เช่นเดียวกับการดำเนินการอื่นๆ กฎการทดสอบแต่ละข้อมี testกลุ่ม exec ที่กำหนดโดยนัย ซึ่ง หากไม่มีการลบล้าง จะมีข้อกำหนดเกี่ยวกับเครื่องมือที่จำเป็นใน @bazel_tools//tools/test:default_test_toolchain_type

Toolchain ประเภทนี้ไม่มีข้อมูลในรูปแบบของผู้ให้บริการ แต่สามารถใช้เพื่อมีอิทธิพลต่อแพลตฟอร์มการดำเนินการของการทดสอบได้

Bazel จะลงทะเบียน Toolchain ดังกล่าว 2 รายการ ซึ่งจะมีผลหากผู้ใช้ไม่ได้ กำหนด Toolchain ของตนเองอย่างชัดเจน::

• หาก--@bazel_tools//tools/test:incompatible_use_default_test_toolchainเปิดใช้ (ค่าเริ่มต้น) ชุดเครื่องมือทดสอบที่ใช้งานอยู่จะเป็น @bazel_tools//tools/test:default_test_toolchain เครื่องมือนี้ต้องมี แพลตฟอร์มการดำเนินการเพื่อให้ตรงกับข้อจำกัดของแพลตฟอร์มเป้าหมายของกฎการทดสอบทั้งหมด

  โดยเฉพาะอย่างยิ่ง แพลตฟอร์มเป้าหมายจะใช้ร่วมกับเครื่องมือนี้ได้ หากมีการลงทะเบียนเป็นแพลตฟอร์มการดำเนินการด้วย หากไม่พบแพลตฟอร์มดังกล่าว กฎการทดสอบจะล้มเหลวพร้อมข้อผิดพลาดในการแก้ไข Toolchain

• หากปิดใช้ --@bazel_tools//tools/test:incompatible_use_default_test_toolchain ไว้ เครื่องมือทดสอบที่ใช้งานอยู่จะเป็น @bazel_tools//tools/test:legacy_test_toolchain เครื่องมือนี้ไม่ได้ กำหนดข้อจำกัดใดๆ ดังนั้นการดำเนินการทดสอบที่ไม่มีข้อจำกัด exec ที่ระบุด้วยตนเอง จึงได้รับการกำหนดค่าสำหรับแพลตฟอร์มการดำเนินการที่ลงทะเบียนเป็นแพลตฟอร์มแรก

  ซึ่งมักจะไม่ใช่ลักษณะการทำงานที่ต้องการในการสร้างหลายแพลตฟอร์ม เนื่องจากอาจส่งผลให้ เช่น ไบนารีทดสอบที่สร้างขึ้นสำหรับ Linux ในเครื่อง Windows ทำงานบน Windows

  เนื่องจากการตั้งค่านี้เป็นแบบเดิม ตัวเลือกนี้จึงอาจไม่พร้อมใช้งานใน Bazel รุ่นต่อๆ ไป

ผู้ใช้สามารถลงทะเบียน Toolchain เพิ่มเติมสำหรับประเภทนี้เพื่อกำหนดลักษณะการทำงานนี้ได้ และ Toolchain ของผู้ใช้จะมีลำดับความสำคัญเหนือ Toolchain เริ่มต้น ผู้เขียนกฎการทดสอบสามารถกำหนดประเภท Toolchain ของการทดสอบของตนเองและลงทะเบียน Toolchain เริ่มต้นสำหรับกฎนั้นได้ด้วย

การตั้งชื่อแท็ก

แท็กบางรายการในกฎการทดสอบมีความหมายพิเศษ นอกจากนี้ โปรดดู สารานุกรมการสร้าง Bazel เกี่ยวกับแอตทริบิวต์ tags ด้วย

แท็ก	ความหมาย
exclusive	อย่าทำการทดสอบอื่นพร้อมกัน
external	การทดสอบมีทรัพยากร Dependency ภายนอก ให้ปิดใช้การแคชการทดสอบ
large	test_suite การประชุม ชุดการทดสอบขนาดใหญ่
manual *	อย่ารวมเป้าหมายการทดสอบในรูปแบบเป้าหมายแบบไวลด์การ์ด เช่น :..., :* หรือ :all
medium	test_suite อนุสัญญา ชุดการทดสอบระดับกลาง
small	test_suite อนุสัญญา ชุดการทดสอบขนาดเล็ก
smoke	test_suite หมายถึงควรเรียกใช้ก่อน ส่งการเปลี่ยนแปลงโค้ดไปยังระบบควบคุมเวอร์ชัน

Runfiles

ในส่วนต่อไปนี้ ให้ถือว่ามีกฎ *_binary() ที่ติดป้ายกำกับ //foo/bar:unittest ซึ่งมีทรัพยากร Dependency ขณะรันไทม์ในกฎที่ติดป้ายกำกับ //deps/server:server

ตำแหน่ง

ไดเรกทอรี runfiles สำหรับเป้าหมาย //foo/bar:unittest คือไดเรกทอรี $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles เส้นทางนี้เรียกว่าrunfiles_dir

แท็กเริ่มการทำงาน

ระบบจะประกาศไดเรกทอรี runfiles เป็นทรัพยากร Dependency ในเวลาคอมไพล์ของกฎ *_binary() ส่วนไดเรกทอรี Runfiles เองจะขึ้นอยู่กับชุดไฟล์ BUILD ที่ส่งผลต่อกฎ *_binary() หรือการขึ้นต่อกันในเวลาคอมไพล์หรือรันไทม์ การแก้ไขไฟล์ต้นฉบับจะไม่ส่งผลต่อโครงสร้างของ ไดเรกทอรี runfiles จึงไม่ทริกเกอร์การสร้างใหม่

เนื้อหา

ไดเรกทอรีไฟล์ที่เรียกใช้จะมีข้อมูลต่อไปนี้

• Symlink ไปยังทรัพยากร Dependency ของรันไทม์: OutputFile และ CommandRule แต่ละรายการซึ่งเป็น ทรัพยากร Dependency ของรันไทม์ของกฎ *_binary() จะแสดงด้วย Symlink หนึ่งรายการ ในไดเรกทอรี runfiles ชื่อของลิงก์สัญลักษณ์คือ $(WORKSPACE)/package_name/rule_name เช่น Symlink สำหรับเซิร์ฟเวอร์ จะมีชื่อว่า $(WORKSPACE)/deps/server/server และเส้นทางแบบเต็มจะเป็น $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server ปลายทางของ Symlink คือ OutputFileName() ของ OutputFile หรือ CommandRule ซึ่งแสดงเป็นเส้นทางสัมบูรณ์ ดังนั้น ปลายทางของ Symlink อาจเป็น $(WORKSPACE)/linux-dbg/deps/server/42/server