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

รายงานปัญหา ดูซอร์สโค้ด รุ่น Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ข้อมูลเบื้องต้น

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

การทดสอบจะทํางานโดยใช้ bazel test

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

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

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

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

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

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

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

คีย์เวิร์ด "ต้อง" "ต้องไม่" "ต้องระบุ" "ต้อง" "ต้องไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" ควรตีความตามที่อธิบายไว้ใน IETF RFC 2119

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

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

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

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

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

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

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

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

บทบาทของผู้เรียกใช้การทดสอบ

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

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

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

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

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

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

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

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

ชุดค่าผสมของป้ายกํากับ size และ timeout ทั้งหมดนั้นถูกต้องตามกฎหมาย ดังนั้นการทดสอบที่ "ใหญ่มาก" อาจมีการประกาศว่ามีการหมดเวลาเป็น "สั้น" เราคาดว่ามันจะทำสิ่งเลวร้ายบางอย่างอย่างรวดเร็ว

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

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

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

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

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

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

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

ทดสอบการแยกข้อมูล

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

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

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

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

บล็อกสภาพแวดล้อมเริ่มต้นจะประกอบไปด้วยข้อมูลต่อไปนี้

ตัวแปร ค่า สถานะ
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 เส้นทางแบบสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ไฟล์นี้ควรใช้เพื่อรายงานข้อผิดพลาดที่มาจากโครงสร้างพื้นฐานการทดสอบเท่านั้น ไม่ใช่เป็นกลไกทั่วไปในการรายงานข้อผิดพลาดที่เกิดความผิดพลาดเป็นพักๆ ของชุดทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานการทดสอบหมายถึงระบบหรือไลบรารีที่ไม่ได้เจาะจงการทดสอบ แต่อาจทําให้การทดสอบไม่สําเร็จเนื่องจากทํางานผิดปกติ บรรทัดแรกคือชื่อคอมโพเนนต์ของโครงสร้างพื้นฐานการทดสอบที่ทําให้เกิดความล้มเหลว ส่วนบรรทัดที่สองคือคําอธิบายความล้มเหลวที่มนุษย์อ่านได้ ระบบจะไม่สนใจบรรทัดเพิ่มเติม) ไม่บังคับ
TEST_LOGSPLITTER_OUTPUT_FILE เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้เพื่อเขียนบันทึก Protobuffer ของ Logsplitter) ไม่บังคับ
TEST_PREMATURE_EXIT_FILE Absolute Path ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้สำหรับจับการเรียก 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 เส้นทางสัมบูรณ์ไปยังฐานของต้นไม้ runfiles ต้องระบุ
TEST_TOTAL_SHARDS total shard count, if sharding is used ไม่บังคับ
TEST_TMPDIR เส้นทางสัมบูรณ์ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ ต้องระบุ
TEST_WORKSPACE ชื่อพื้นที่ทํางานของที่เก็บข้อมูลในเครื่อง ไม่บังคับ
TEST_UNDECLARED_OUTPUTS_DIR Absolute Path ที่นำไปยังไดเรกทอรีส่วนตัวที่เขียนได้ (ใช้สำหรับเขียนเอาต์พุตการทดสอบที่ไม่ได้ประกาศ) ระบบจะใส่ไฟล์ที่เขียนลงในไดเรกทอรี TEST_UNDECLARED_OUTPUTS_DIR ไว้ในไฟล์ ZIP และเพิ่มลงในไฟล์ 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 ไม่จำกัด หรือ 2044 KB <= rlim <= 8192 KB

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

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

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

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

ระบบไฟล์

ไดเรกทอรีรูทที่การทดสอบพบอาจเป็นหรือไม่ใช่ไดเรกทอรีรูทจริง

/proc จะติดตั้ง

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

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

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

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

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

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

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

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

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

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

เครือข่าย

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

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

การทดสอบจะได้รับสิทธิ์ใช้ CPU อย่างน้อย 1 คอร์ อุปกรณ์อื่นๆ อาจใช้ได้เช่นกัน แต่เราไม่รับประกัน ไม่ได้ระบุแง่มุมด้านประสิทธิภาพอื่นๆ ของแกนนี้ คุณสามารถเพิ่มการจองให้ใช้แกน CPU มากขึ้นได้โดยเพิ่มแท็ก "cpu:n" (โดยที่ n เป็นจำนวนบวก) ลงในกฎทดสอบ หากเครื่องมีจำนวนแกน CPU ทั้งหมดน้อยกว่าที่ขอ Bazel จะยังคงทำการทดสอบ หากการทดสอบใช้การแยกข้อมูล แต่ละกลุ่มจะจองจำนวนแกน CPU ที่ระบุไว้ที่นี่

การทดสอบอาจสร้างกระบวนการย่อย แต่ไม่สร้างกลุ่มกระบวนการหรือเซสชัน

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

เวลาและวันที่

ไม่ได้ระบุเวลาและวันที่ปัจจุบัน ไม่ได้ระบุเขตเวลาของระบบ

อาจมีหรือไม่มี X Windows ก็ได้ การทดสอบที่ต้องใช้เซิร์ฟเวอร์ X ควรเริ่มด้วย vgfb

ทดสอบการโต้ตอบกับระบบไฟล์

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

การทดสอบควรสร้างไฟล์ภายในไดเรกทอรีที่ระบุโดย $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 หรือส่วนอื่นๆ ของสภาพแวดล้อมการเรียกใช้ที่มีไว้เพื่อทำให้ไฟล์อินพุตพร้อมใช้งานโดยเฉพาะ

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

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

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

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

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

รูปแบบแท็ก

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

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

ไฟล์รันไทม์

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

ตำแหน่ง

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

การอ้างอิง

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

เนื้อหา

ไดเรกทอรี runfiles มีสิ่งต่อไปนี้

  • ลิงก์สัญลักษณ์ไปยังทรัพยากรที่ต้องใช้ในรันไทม์: ไฟล์เอาต์พุตและ CommandRule แต่ละรายการที่เป็นทรัพยากรที่ต้องใช้ในรันไทม์ของกฎ *_binary() จะแสดงด้วยลิงก์สัญลักษณ์ 1 รายการในไดเรกทอรี runfiles ชื่อของลิงก์สัญลักษณ์คือ $(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
  • Symlink ไปยังไฟล์รันไทม์ย่อย: สําหรับ *_binary() Z แต่ละรายการที่เป็นทรัพยากรที่ *_binary() C ต้องใช้รันไทม์ จะมีลิงก์ที่ 2 ในไดเรกทอรีไฟล์รันไทม์ของ C ไปยังไฟล์รันไทม์ของ Z ชื่อของลิงก์สัญลักษณ์คือ $(WORKSPACE)/package_name/rule_name.runfiles เป้าหมายของลิงก์สัญลักษณ์คือไดเรกทอรี runfiles เช่น โปรแกรมย่อยทั้งหมดใช้ไดเรกทอรี runfiles ร่วมกัน