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

รายงานปัญหา ดูแหล่งที่มา รุ่น Nightly · 7.4 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทบาทของผู้ดำเนินการทดสอบ

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

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

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

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

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

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

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

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

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

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

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

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

เวลานอก เวลาต่ำสุด (วินาที)
วิดีโอสั้น 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 ไม่ได้ตั้งค่า จำเป็น
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 Absolute Path ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้ในการเขียน บันทึก Protobuffer ของ Logplitter) ไม่บังคับ
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 Absolute Path ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ จำเป็น
TEST_WORKSPACE ชื่อพื้นที่ทํางานของที่เก็บข้อมูลในเครื่อง ไม่บังคับ
TEST_UNDECLARED_OUTPUTS_DIR Absolute Path ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ (ใช้ในการเขียนที่ไม่ได้ประกาศ เอาต์พุตทดสอบ) ไฟล์ใดๆ ที่เขียนไปยัง ระบบจะซิปไดเรกทอรี TEST_UNDECLARED_OUTPUTS_DIR และ เพิ่มลงในไฟล์ outputs.zip แล้วใต้ bazel-testlogs ไม่บังคับ
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR เส้นทางแบบสัมบูรณ์ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ (ใช้สำหรับเขียนคำอธิบายประกอบเอาต์พุตการทดสอบ .part และ .pb ที่ไม่ได้ประกาศ) ไม่บังคับ
TEST_WARNINGS_OUTPUT_FILE Absolute Path ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้ในการเขียน) คำเตือนเป้าหมายการทดสอบ) ไม่บังคับ
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) จะเปิดสำหรับการเขียน แต่ไม่ได้ระบุสิ่งที่แนบมา ซึ่งอาจเป็นเทอร์มินัล ไปป์ ไฟล์ปกติ หรือสิ่งอื่นๆ ที่เขียนอักขระได้ พวกเขาอาจแชร์รายการในตารางไฟล์ที่เปิดอยู่ (หมายความว่าไม่สามารถค้นหาได้อย่างอิสระ) การทดสอบไม่ควรรับค่าจากตัวระบุไฟล์ที่เปิดอยู่อื่นๆ

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

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

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

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

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

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

รูปแบบแท็ก

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

แท็ก ความหมาย
exclusive ไม่ทำการทดสอบอื่นในเวลาเดียวกัน
external test มี Dependency ภายนอก ปิดใช้การแคชการทดสอบ
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() ไดเรกทอรี Runfiles เองก็ขึ้นอยู่กับชุดของ BUILD ไฟล์ที่มีผลต่อกฎ *_binary() หรือเวลาคอมไพล์หรือรันไทม์ใดๆ ของกฎ ทรัพยากร Dependency การแก้ไขไฟล์ต้นฉบับไม่ได้ส่งผลกระทบต่อโครงสร้างของไฟล์ต้นฉบับ ดังนั้น จึงจะไม่ทริกเกอร์การสร้างใหม่

เนื้อหา

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

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