ข้อกำหนดที่ครอบคลุมเกี่ยวกับสภาพแวดล้อมการทดสอบ
ข้อมูลเบื้องต้น
ภาษา 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 ร่วมกัน