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

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ที่มา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กฎการทดสอบคล้ายกับกฎไบนารีตรงที่แต่ละกฎต้องแสดงไฟล์ปฏิบัติการ ของโปรแกรม สำหรับบางภาษา โปรแกรมนี้เป็นโปรแกรมต้นขั้วซึ่งรวม การควบคุมเฉพาะภาษาด้วยรหัสทดสอบ กฎการทดสอบจะต้องระบุ ได้ด้วย นอกเหนือจากไฟล์ปฏิบัติการทดสอบหลัก ตัวดำเนินการทดสอบ จะต้องมีไฟล์ 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" กำลังใช้ตะเกียง--test_verbose_timeout_warnings ตัวเลือกบรรทัดคำสั่งจะแสดงการทดสอบที่มีขนาดที่ระบุใหญ่เกินไป

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

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

ทดสอบชาร์ดดิ้ง

การทดสอบสามารถทำพร้อมกันได้ผ่านชาร์ดดิ้งทดสอบ โปรดดู --test_sharding_strategy และ shard_count ไปยัง เปิดใช้ทดสอบชาร์ดดิ้ง เมื่อเปิดใช้ชาร์ดดิ้ง ตัวดำเนินการทดสอบจะเปิดขึ้น 1 ครั้ง ต่อชาร์ด ตัวแปรสภาพแวดล้อม TEST_TOTAL_SHARDS คือจำนวนชาร์ด และ TEST_SHARD_INDEX คือจำนวนชาร์ด ดัชนีชาร์ดเริ่มต้นที่ 0 ผู้วิ่งใช้ข้อมูลนี้เพื่อเลือกการทดสอบ เช่น การใช้กลยุทธ์แบบพบกันหมด ตัวดำเนินการทดสอบบางคนอาจไม่รองรับ ชาร์ดดิ้ง หากรันเนอร์รองรับการชาร์ดดิ้ง ก็ต้องสร้างหรืออัปเดต วันที่แก้ไขของไฟล์ที่ระบุโดย TEST_SHARD_STATUS_FILE มิเช่นนั้น หาก --incompatible_check_sharding_support เปิดใช้อยู่ 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 Absolute Path ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ไฟล์นี้ ควรใช้เพื่อรายงานความล้มเหลวที่เกิดจากการทดสอบเท่านั้น ไม่ใช่กลไกทั่วไปในการรายงานความล้มเหลวที่ไม่สม่ำเสมอ ของการทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานการทดสอบหมายถึงระบบ หรือไลบรารีที่ไม่ได้เจาะจงการทดสอบ แต่อาจทำให้การทดสอบล้มเหลวได้โดย ที่ทำงานผิดปกติ บรรทัดแรกเป็นชื่อของโครงสร้างพื้นฐานการทดสอบ คอมโพเนนต์ที่ 2 ทำให้เกิดความล้มเหลว องค์ประกอบที่ 2 คือคอมโพเนนต์ที่มนุษย์อ่านได้ คำอธิบายความล้มเหลว ระบบจะไม่สนใจบรรทัดเพิ่มเติม) ไม่บังคับ
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 Absolute Path ที่นำไปยังฐานของแผนผังรันไฟล์ จำเป็น
TEST_TOTAL_SHARDS ทั้งหมด shard count หากใช้ sharding ไม่บังคับ
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 Absolute Path ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ (ใช้ในการเขียนที่ไม่ได้ประกาศ ทดสอบคำอธิบายประกอบ .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) จะต้องเปิดสำหรับการเขียน แต่สิ่งที่แนบมาด้วยคือ ไม่ระบุ ซึ่งอาจเป็น Terminal, ไปป์, ไฟล์ทั่วไป หรืออื่นๆ ก็ได้ ที่เขียนอักขระได้ พวกเขาอาจแชร์รายการในตารางไฟล์ที่เปิดอยู่ (หมายความว่าไม่สามารถค้นหาได้อย่างอิสระ) การทดสอบไม่ควรรับค่าใดๆ ตัวบ่งชี้ไฟล์อื่นๆ ที่เปิดอยู่

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 เขียนได้ แต่การทดสอบควรหลีกเลี่ยงการใช้เส้นทางเหล่านี้

การทดสอบต้องไม่สรุปว่าเส้นทางคงที่ใดๆ พร้อมใช้งานสำหรับ

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

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

ต้องมีรูทของผู้ใช้, Nobody และ unittest รูทของกลุ่ม ไม่มีใคร และ ภาษาอังกฤษต้องมีอยู่จริง

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

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

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

เครือข่าย

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

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

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

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

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

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

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

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

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

รูปแบบแท็ก

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

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

ไฟล์เรียกใช้

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

เนื้อหา

ไดเรกทอรี Runfiles ประกอบด้วยข้อมูลต่อไปนี้

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