ข้อกำหนดอย่างละเอียดของสภาพแวดล้อมการดำเนินการทดสอบ
ที่มา
ภาษา Bazel BUILD มีกฎที่ใช้กำหนดโปรแกรมทดสอบอัตโนมัติในหลายภาษาได้
การทดสอบจะดำเนินการโดยใช้ bazel test
ผู้ใช้อาจดำเนินการไบนารีทดสอบโดยตรงได้เช่นกัน ซึ่งทำได้แต่ไม่ได้รับการสนับสนุน เนื่องจากคำขอดังกล่าวจะไม่เป็นไปตามคำสั่งที่อธิบายไว้ด้านล่าง
การทดสอบควรอิงตามธรรมชาติ กล่าวคือ การทดสอบควรเข้าถึงเฉพาะทรัพยากรที่มีทรัพยากร Dependency ที่ประกาศแล้วเท่านั้น หากการทดสอบไม่ได้มีความต่อเนื่องกันอย่างถูกต้อง ก็จะไม่ให้ผลลัพธ์ที่เคยเกิดขึ้นซ้ำอีก ซึ่งอาจเป็นปัญหาสำคัญในการหาสาเหตุของปัญหา (การพิจารณาว่าการเปลี่ยนแปลงใดทำให้การทดสอบมีปัญหา), เผยแพร่ความสามารถในการตรวจสอบด้านวิศวกรรม และการแยกทรัพยากรของการทดสอบ (เฟรมเวิร์กการทดสอบอัตโนมัติไม่ควรใช้ DDOS กับเซิร์ฟเวอร์ เนื่องจากมีการทดสอบบางอย่างเกิดขึ้นกับเซิร์ฟเวอร์)
วัตถุประสงค์
เป้าหมายของหน้านี้คือการสร้างสภาพแวดล้อมรันไทม์อย่างเป็นทางการสำหรับพฤติกรรมที่คาดหวังของการทดสอบ Bazel นอกจากนี้ยังจะกำหนดข้อกำหนดให้กับตัวดำเนินการทดสอบและระบบบิลด์ด้วย
ข้อมูลจำเพาะของสภาพแวดล้อมการทดสอบช่วยให้ผู้เขียนการทดสอบหลีกเลี่ยงการพึ่งพาลักษณะการทำงานที่ไม่ระบุได้ จึงทำให้โครงสร้างพื้นฐานของการทดสอบมีอิสระมากขึ้นในการเปลี่ยนแปลงการติดตั้งใช้งาน ข้อกำหนดดังกล่าวช่วยขจัดช่องโหว่ให้แน่นหนาขึ้นซึ่งทำให้การทดสอบจำนวนมากผ่านได้ในปัจจุบันแม้จะไม่ได้มีความสละสลวย กำหนดการตัดสินใจ และผู้มีส่วนร่วมอย่างถูกต้อง
หน้านี้มีวัตถุประสงค์เพื่อให้ข้อมูลเชิงบรรทัดฐานและความน่าเชื่อถือ หากข้อกำหนดนี้และลักษณะการใช้งานของตัวดำเนินการทดสอบไม่ตรงกัน ข้อกำหนดจะมีความสำคัญเหนือกว่า
ข้อกำหนดที่เสนอ
คำว่า "ต้อง" "ต้องไม่" "จำเป็น" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" ให้ตีความว่า ตามที่อธิบายไว้ใน IETF RFC 2119
วัตถุประสงค์ของการทดสอบ
วัตถุประสงค์ของการทดสอบ Bazel คือการยืนยันพร็อพเพอร์ตี้บางอย่างของไฟล์ต้นฉบับที่มีการตรวจสอบในที่เก็บ (ในหน้านี้ "ไฟล์ต้นฉบับ" จะรวมข้อมูลการทดสอบ เอาต์พุตสีทอง และอื่นๆ ที่อยู่ในการควบคุมเวอร์ชัน) ผู้ใช้คนหนึ่งเขียนการทดสอบเพื่อยืนยันค่าคงที่ที่พวกเขาคาดว่าจะได้รับการบำรุงรักษา ผู้ใช้คนอื่นๆ จะดำเนินการทดสอบในภายหลังเพื่อตรวจสอบว่าค่าตัวแปรไม่สมบูรณ์หรือไม่ หากการทดสอบขึ้นอยู่กับตัวแปรอื่นนอกเหนือจากไฟล์ต้นฉบับ (แบบไม่อิงตามเงื่อนไข) ค่าของการทดสอบจะลดลง เนื่องจากผู้ใช้ในภายหลังไม่มั่นใจว่าการเปลี่ยนแปลงของตนเองเป็นความผิดพลาดเมื่อการทดสอบหยุดผ่าน
ดังนั้น ผลการทดสอบต้องขึ้นอยู่กับสิ่งต่อไปนี้เท่านั้น
- ไฟล์ต้นฉบับที่การทดสอบมีทรัพยากร Dependency ที่ประกาศแล้ว
- ผลิตภัณฑ์ของระบบบิลด์ที่การทดสอบมีทรัพยากร Dependency ที่ประกาศแล้ว
- ทรัพยากรที่ตัวดำเนินการทดสอบรับประกันได้ว่าพฤติกรรมจะคงเดิม
ขณะนี้ยังไม่มีการบังคับใช้ลักษณะการทำงานดังกล่าว อย่างไรก็ตาม ผู้ดำเนินการทดสอบขอสงวนสิทธิ์ในการเพิ่มการบังคับใช้ดังกล่าวในอนาคต
บทบาทของระบบบิลด์
กฎการทดสอบคล้ายกับกฎไบนารีตรงที่แต่ละกฎต้องแสดงโปรแกรมที่เรียกใช้ได้ สำหรับบางภาษา โปรแกรมนี้เป็นโปรแกรม Stub ที่รวมเทคโนโลยีเฉพาะภาษาเข้ากับโค้ดทดสอบ โดยกฎการทดสอบจะต้องสร้างเอาต์พุตอื่นๆ ด้วย นอกเหนือจากไฟล์ปฏิบัติการทดสอบหลัก ตัวดำเนินการทดสอบจะต้องมีไฟล์ Manifest ของ runfiles ซึ่งเป็นไฟล์อินพุตที่ควรพร้อมใช้งานสำหรับการทดสอบขณะรันไทม์ และอาจต้องใช้ข้อมูลเกี่ยวกับประเภท ขนาด และแท็กของการทดสอบ
ระบบบิลด์อาจใช้ไฟล์รันไฟล์เพื่อส่งโค้ดและข้อมูล (อาจใช้เป็นการเพิ่มประสิทธิภาพเพื่อทำให้ไบนารีของการทดสอบแต่ละรายการเล็กลงด้วยการแชร์ไฟล์ระหว่างการทดสอบ เช่น ผ่านการใช้การลิงก์แบบไดนามิก) ระบบในบิลด์ควรตรวจสอบว่าไฟล์ปฏิบัติการที่สร้างขึ้นโหลดไฟล์เหล่านี้ผ่านอิมเมจ Runfile ที่มาจากตัวดำเนินการทดสอบ แทนที่จะเป็นการอ้างอิงแบบฮาร์ดโค้ดไปยังตำแหน่งสัมบูรณ์ในซอร์สหรือแผนผังเอาต์พุต
บทบาทของผู้ดำเนินการทดสอบ
จากมุมมองของตัวดำเนินการทดสอบ การทดสอบแต่ละครั้งคือโปรแกรมที่จะเรียกใช้ execve()
ได้ อาจมีวิธีอื่นๆ ในการดำเนินการทดสอบ เช่น IDE อาจอนุญาตให้เรียกใช้การทดสอบ Java ในกระบวนการ อย่างไรก็ตาม ผลของการทดสอบเป็นกระบวนการแบบสแตนด์อโลนต้องถือว่าเชื่อถือได้ หากกระบวนการทดสอบทำงานจนเสร็จสิ้นและสิ้นสุดตามปกติโดยมีโค้ดสำหรับออกเป็น 0 แสดงว่าการทดสอบได้ผ่านไปแล้ว ผลลัพธ์อื่นๆ จะถือว่าเป็นการทดสอบความล้มเหลว โดยเฉพาะอย่างยิ่ง การเขียนสตริง PASS
หรือ FAIL
ไปยัง Studout ไม่มีนัยสำคัญต่อตัวดำเนินการทดสอบ
หากการทดสอบใช้เวลาดำเนินการนานเกินไป เกินขีดจำกัดทรัพยากรบางรายการ หรือตัวดำเนินการทดสอบตรวจพบลักษณะการทำงานที่ไม่ได้รับอนุญาต ระบบอาจเลือกยุติการทดสอบและถือว่าการเรียกใช้นั้นเป็นความล้มเหลว ผู้เรียกใช้ต้องไม่รายงานการทดสอบว่าผ่านหลังจากส่งสัญญาณไปยังกระบวนการทดสอบหรือเหตุการณ์ย่อยใดๆ
เป้าหมายการทดสอบทั้งหมด (ไม่ใช่วิธีหรือการทดสอบแต่ละรายการ) จะมีระยะเวลาที่จำกัดในการทำงานให้เสร็จสมบูรณ์ การจำกัดเวลาสำหรับการทดสอบจะอิงตามแอตทริบิวต์ timeout
ของการทดสอบในตารางต่อไปนี้
เวลานอก | ขีดจำกัดเวลา (วินาที) |
---|---|
วิดีโอสั้น | 60 |
ปานกลาง | 300 |
long | 900 |
นิรันดร์ | 3,600 |
การทดสอบที่ไม่ได้ระบุระยะหมดเวลาไว้อย่างชัดแจ้งจะมี 1 คำโดยนัยตาม size
ของการทดสอบ ดังนี้
ขนาด | ป้ายกำกับการหมดเวลาโดยนัย |
---|---|
เล็ก | วิดีโอสั้น |
medium | ปานกลาง |
ใหญ่ | long |
มหึมา | นิรันดร์ |
การทดสอบ "ขนาดใหญ่" ที่ไม่มีการตั้งค่าระยะหมดเวลาที่ชัดเจนจะได้รับการจัดสรรเวลา 900 วินาทีในการทำงาน การทดสอบ "ปานกลาง" ที่มีระยะหมดเวลาเป็น "สั้น" จะได้รับการจัดสรรเวลา 60 วินาที
size
ต่างจาก timeout
ตรงที่จะกําหนดการใช้งานสูงสุดที่คาดไว้ของทรัพยากรอื่นๆ (เช่น RAM) เมื่อทําการทดสอบในเครื่อง ตามที่อธิบายไว้ในคําจํากัดความทั่วไป
ชุดค่าผสมของป้ายกำกับ size
และ timeout
ทั้งหมดถือว่าถูกต้องตามกฎหมาย อาจมีการประกาศว่าการทดสอบที่ "มหาศาล" มีระยะหมดเวลาเป็น "สั้น" ซึ่งน่าจะทำบางสิ่งที่เลวร้ายมาก
ได้อย่างรวดเร็ว
การทดสอบอาจแสดงผลอย่างรวดเร็วทันทีโดยไม่คำนึงถึงระยะหมดเวลา การทดสอบไม่ถูกลงโทษสำหรับการหมดเวลาที่มากเกินไป แต่เราอาจมีการเตือน โดยคุณควรตั้งค่าระยะหมดเวลาให้แคบที่สุดเท่าที่จะทำได้โดยไม่ทำให้เกิดความไม่สม่ำเสมอ
ระยะหมดเวลาของการทดสอบลบล้างได้ด้วยแฟล็ก --test_timeout
แบบเบซเลนเมื่อทำงานด้วยตนเองภายใต้เงื่อนไขที่ทราบแล้วว่าทำงานช้า ค่า --test_timeout
จะมีหน่วยเป็นวินาที ตัวอย่างเช่น --test_timeout=120
ตั้งค่าระยะหมดเวลาของการทดสอบเป็น 2 นาที
นอกจากนี้ ยังมีขอบเขตล่างที่แนะนำสำหรับระยะหมดเวลาทดสอบดังนี้
เวลานอก | เวลาขั้นต่ำ (วินาที) |
---|---|
วิดีโอสั้น | 0 |
ปานกลาง | 30 |
long | 300 |
นิรันดร์ | 900 |
ตัวอย่างเช่น หากการทดสอบ "ปานกลาง" เสร็จสมบูรณ์ใน 5.5 วินาที ให้พิจารณาตั้งค่า timeout =
"short"
หรือ size = "small"
การใช้ตัวเลือกบรรทัดคำสั่ง --test_verbose_timeout_warnings
ของ bazel จะแสดงการทดสอบที่มีขนาดที่ระบุใหญ่เกินไป
ขนาดและระยะหมดเวลาทดสอบจะระบุไว้ในไฟล์ "สร้าง" ตามข้อกำหนดที่นี่ หากไม่ระบุ ขนาดของการทดสอบจะมีค่าเริ่มต้นเป็น "ปานกลาง"
หากกระบวนการหลักของการทดสอบสิ้นสุดลง แต่กระบวนการย่อยบางส่วนยังคงทำงานอยู่ ผู้ดำเนินการทดสอบควรพิจารณาว่าการเรียกใช้นั้นเสร็จสมบูรณ์และนับว่าเป็นความสำเร็จหรือล้มเหลว โดยอิงตามโค้ดสำหรับออกที่สังเกตได้จากกระบวนการหลัก ตัวดำเนินการทดสอบ อาจปิดกระบวนการที่รบกวนได้ การทดสอบไม่ควรทำให้กระบวนการรั่วไหลในลักษณะนี้
ทดสอบชาร์ดดิ้ง
การทดสอบสามารถทำพร้อมกันได้ผ่านชาร์ดดิ้งทดสอบ ดู --test_sharding_strategy
และ shard_count
เพื่อเปิดใช้ชาร์ดดิ้งทดสอบ เมื่อเปิดใช้การชาร์ด ตัวดำเนินการทดสอบจะทำงาน 1 ครั้งต่อชาร์ด ตัวแปรสภาพแวดล้อม TEST_TOTAL_SHARDS
คือจำนวนชาร์ดและ TEST_SHARD_INDEX
คือดัชนีชาร์ดที่เริ่มต้นที่ 0 นักวิ่งใช้ข้อมูลนี้เพื่อเลือกการทดสอบที่จะเรียกใช้
เช่น การใช้กลยุทธ์แบบพบกันหมด นักทดสอบบางคนอาจไม่สนับสนุน
การชาร์ดดิ้ง หากโปรแกรมเรียกใช้รองรับการชาร์ดดิ้ง โปรแกรมจะต้องสร้างหรืออัปเดตวันที่แก้ไขล่าสุดของไฟล์ที่ระบุโดย TEST_SHARD_STATUS_FILE
มิเช่นนั้น หากเปิดใช้ --incompatible_check_sharding_support
ไว้ Bazel จะทดสอบไม่สำเร็จหากมีการชาร์ด
เงื่อนไขเริ่มต้น
ขณะทำการทดสอบ ผู้ดำเนินการทดสอบต้องกำหนดเงื่อนไขเริ่มต้นบางประการ
ผู้ดำเนินการทดสอบต้องเรียกใช้การทดสอบแต่ละรายการด้วยเส้นทางไปยังไฟล์ปฏิบัติการทดสอบใน argv[0]
เส้นทางนี้ต้องสัมพันธ์กันและอยู่ใต้ไดเรกทอรีปัจจุบันของการทดสอบ
(ซึ่งอยู่ในโครงสร้างไฟล์ Runfiles ดูด้านล่าง) ตัวดำเนินการทดสอบไม่ควรส่งอาร์กิวเมนต์อื่นๆ ในการทดสอบ เว้นแต่ผู้ใช้จะร้องขออย่างชัดแจ้ง
บล็อกสภาพแวดล้อมเริ่มต้นจะประกอบไปด้วยดังต่อไปนี้
ตัวแปร | ค่า | สถานะ |
---|---|---|
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 คือคำอธิบายของความล้มเหลวที่มนุษย์อ่านได้ ระบบจะไม่สนใจบรรทัดเพิ่มเติม) | ไม่บังคับ |
TEST_LOGSPLITTER_OUTPUT_FILE |
เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้ในการเขียนบันทึก Probuffer ของ 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
) แต่ไม่ได้ระบุข้อมูลที่แนบมาด้วย ซึ่งอาจเป็นเทอร์มินัล ไปป์ ไฟล์ปกติ หรืออะไรก็ตามที่อักขระสามารถเขียนได้ โดยอาจแชร์รายการในตารางไฟล์ที่เปิดอยู่ (หมายความว่าไม่สามารถค้นหาข้อมูลได้อย่างอิสระ) การทดสอบไม่ควรรับค่าข้อบ่งชี้ไฟล์อื่นๆ ที่เปิดอยู่
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 ต้องมีรากของกลุ่ม ไม่มีใคร และ 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 หรือส่วนอื่นๆ ของสภาพแวดล้อมการดำเนินการที่มีวัตถุประสงค์เพื่อทำให้ไฟล์อินพุตพร้อมใช้งานโดยเฉพาะ
การทดสอบต้องไม่เข้าถึงเอาต์พุตอื่นๆ ของระบบบิลด์ที่เส้นทางที่อนุมานจากตำแหน่งของไฟล์ปฏิบัติการของตัวเอง
ไม่มีการระบุว่าโครงสร้างการเรียกใช้ไฟล์มีไฟล์ทั่วไป ลิงก์สัญลักษณ์ หรือปนกัน โครงสร้าง Runfiles อาจมีลิงก์สัญลักษณ์ไปยังไดเรกทอรี
การทดสอบควรหลีกเลี่ยงการใช้เส้นทางที่มีคอมโพเนนต์ ..
ภายในโครงสร้างไฟล์ Runfile
ไม่ควรเขียนไดเรกทอรี ไฟล์ หรือลิงก์สัญลักษณ์ภายในโครงสร้างการเรียกใช้ไฟล์ (รวมถึงเส้นทางที่ข้ามผ่านลิงก์สัญลักษณ์) (ซึ่งเป็นไปตามที่ไดเรกทอรีที่ทำงานเริ่มต้น
ไม่ควรเขียนได้) การทดสอบต้องไม่คาดเดาว่าไฟล์เรียกใช้ส่วนใดเขียนได้หรือเป็นของผู้ใช้ปัจจุบัน (เช่น chmod
และ chgrp
อาจล้มเหลว)
โครงสร้าง Runfile (รวมถึงเส้นทางที่ข้ามผ่านลิงก์สัญลักษณ์) ต้องไม่เปลี่ยนแปลงระหว่างการดำเนินการทดสอบ การต่อเชื่อมไดเรกทอรีระดับบนสุดและการต่อเชื่อมระบบไฟล์ต้องไม่เปลี่ยนแปลงไม่ว่าในลักษณะใดที่ส่งผลต่อการแก้ไขเส้นทางภายในโครงสร้างของการเรียกใช้ไฟล์
การทดสอบอาจสร้างไฟล์ตามเส้นทางที่ 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
โดยมีการอ้างอิงเวลารันไทม์ตามกฎที่ติดป้ายกำกับ //deps/server:server
ตำแหน่ง
ไดเรกทอรี Runfiles ของเป้าหมาย //foo/bar:unittest
คือไดเรกทอรี $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles
เส้นทางนี้เรียกว่า runfiles_dir
การอ้างอิง
ไดเรกทอรี Runfiles ได้รับการประกาศว่าเป็นทรัพยากร Dependency เวลาคอมไพล์ของกฎ *_binary()
ตัวไดเรกทอรีของ Runfiles จะขึ้นอยู่กับชุดของไฟล์ BUILD ที่ส่งผลต่อกฎ *_binary()
หรือเวลาคอมไพล์หรือเวลาเริ่มคอมไพล์ การแก้ไขไฟล์ต้นฉบับไม่ส่งผลต่อโครงสร้างของไดเรกทอรีรันไฟล์ จึงไม่ทำให้เกิดการสร้างใหม่
เนื้อหา
ไดเรกทอรี Runfiles ประกอบด้วยข้อมูลต่อไปนี้
- ลิงก์สัญลักษณ์ไปยังทรัพยากร Dependency ขณะเรียกใช้: OutputFile และ CommandRule แต่ละรายการที่เป็นทรัพยากร Dependency แบบรันไทม์ของกฎ
*_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
- ลิงก์สัญลักษณ์ไปยังไฟล์การเรียกใช้ย่อย: สำหรับ
*_binary()
Z ทั้งหมดที่ขึ้นต่อเวลาของ*_binary()
C จะมีลิงก์ที่สองในไดเรกทอรีการเรียกใช้ไฟล์ของ C ไปยังรันไฟล์ของ Z ชื่อของลิงก์สัญลักษณ์คือ$(WORKSPACE)/package_name/rule_name.runfiles
เป้าหมายของลิงก์สัญลักษณ์คือ ไดเรกทอรี Runfiles เช่น โปรแกรมย่อยทั้งหมดจะแชร์ไดเรกทอรีการเรียกใช้ไฟล์ทั่วไป