ข้อกำหนดอย่างละเอียดของสภาพแวดล้อมการดำเนินการทดสอบ
ที่มา
ภาษา Bazel BUILD มีกฎที่สามารถใช้เพื่อกำหนดโปรแกรมทดสอบอัตโนมัติในหลายภาษา
การทดสอบจะดำเนินการโดยใช้ bazel test
ผู้ใช้อาจเรียกใช้ไบนารีทดสอบโดยตรง เราอนุญาตแต่ไม่ได้รับการรับรอง เนื่องจากคำขอดังกล่าวไม่เป็นไปตามข้อกำหนดที่อธิบายไว้ด้านล่าง
การทดสอบควรเป็นแบบผลัดกันเล่น กล่าวคือ ต้องเข้าถึงเฉพาะทรัพยากรที่มีทรัพยากร Dependency ที่ประกาศไว้เท่านั้น หากการทดสอบไม่ได้ชัดเจนอย่างถูกต้อง การทดสอบก็ไม่ได้ให้ผลลัพธ์ที่สามารถทำให้เกิดซ้ำได้ในอดีต นี่อาจเป็นปัญหาสำคัญในการค้นหาผู้ต้องหา (ระบุว่าการเปลี่ยนแปลงใดทำให้การทดสอบเสียหาย) เผยแพร่ความสามารถในการตรวจสอบทางวิศวกรรม และการแยกทรัพยากรของการทดสอบ (เฟรมเวิร์กการทดสอบอัตโนมัติไม่ใช่ DDOS ในเซิร์ฟเวอร์เพราะการทดสอบบางอย่างเกิดขึ้นจากเซิร์ฟเวอร์)
วัตถุประสงค์
เป้าหมายของหน้านี้คือการสร้างสภาพแวดล้อมรันไทม์อย่างเป็นทางการสำหรับและลักษณะการทำงานที่คาดไว้ของการทดสอบ Bazel นอกจากนี้ยังกำหนดข้อกำหนดของตัวดำเนินการทดสอบและระบบบิลด์
ข้อกำหนดของสภาพแวดล้อมการทดสอบช่วยให้ผู้เขียนทดสอบหลีกเลี่ยงการพึ่งพาพฤติกรรมที่ไม่ระบุ และทำให้โครงสร้างพื้นฐานการทดสอบมีอิสระมากขึ้นในการเปลี่ยนแปลงการนำไปใช้งาน ข้อกำหนดจะทำให้ช่องบางช่องโหว่ลงผ่านการทดสอบหลายครั้งแม้จะไม่ได้ผ่อนปรน เปี่ยมด้วยความหมาย ไม่สม่ำเสมอ
หน้านี้มีจุดประสงค์เพื่อเป็นทั้งบรรทัดฐานและความน่าเชื่อถือ หากข้อกำหนดนี้และพฤติกรรมการใช้ตัวดำเนินการทดสอบมีความขัดแย้งกัน ข้อกำหนดดังกล่าวจะมีความสำคัญเหนือกว่า
ข้อกำหนดที่นำเสนอ
คำสำคัญที่ว่า "ต้อง" "ต้องไม่" "จำเป็น" "จะ" "จะไม่" "ควร" "ไม่ควร" "แนะนำ" "อาจ" และ "ไม่บังคับ" ได้รับการตีความตามที่อธิบายไว้ใน IETF RFC 2119
วัตถุประสงค์ของการทดสอบ
วัตถุประสงค์ของการทดสอบ Bazel คือการยืนยันพร็อพเพอร์ตี้บางรายการของไฟล์ต้นฉบับที่ตรวจสอบในที่เก็บ (ในหน้านี้ "ซอร์สไฟล์" จะมีข้อมูลการทดสอบ เอาต์พุต Golden และข้อมูลอื่นๆ ที่ควบคุมเวอร์ชัน) ผู้ใช้คนหนึ่งเขียนการทดสอบเพื่อยืนยันค่าความแปรปรวนที่ต้องการคงไว้ ผู้ใช้รายอื่นทำการทดสอบในภายหลังเพื่อตรวจสอบว่าค่าคงที่ได้เสียหายหรือไม่ หากการทดสอบขึ้นอยู่กับตัวแปรอื่นๆ ที่ไม่ใช่ไฟล์ต้นฉบับ (ไม่ผ่อนปรน) ค่าของตัวแปรจะลดลง เนื่องจากผู้ใช้ในภายหลังจะไม่แน่ใจว่าการเปลี่ยนแปลงนั้นเกิดจากความผิดพลาด เมื่อการทดสอบหยุดผ่านหรือไม่
ดังนั้นผลลัพธ์ของการทดสอบจึงขึ้นอยู่กับปัจจัยต่อไปนี้เท่านั้น
- ไฟล์ต้นฉบับที่การทดสอบมีทรัพยากร Dependency ที่ประกาศแล้ว
- ผลิตภัณฑ์ของระบบบิลด์ที่การทดสอบมีการขึ้นต่อกันที่ประกาศไว้
- ของทรัพยากรที่ผู้ทำการทดสอบรับประกันว่าพฤติกรรมนั้นคงที่
ลักษณะการทำงานเช่นนี้ยังไม่ได้บังคับใช้ในขณะนี้ อย่างไรก็ตาม ผู้ดำเนินการทดสอบขอสงวนสิทธิ์ในการเพิ่มการบังคับใช้ดังกล่าวในอนาคต
บทบาทของระบบบิลด์
กฎการทดสอบคล้ายกับกฎไบนารีตรงที่แต่ละกฎต้องมีโปรแกรมที่ดำเนินการได้ สำหรับบางภาษา นี่คือโปรแกรม Stub ซึ่งรวมสายมัดเฉพาะภาษาเข้ากับโค้ดการทดสอบ กฎการทดสอบต้องสร้าง เอาต์พุตอื่นๆ ด้วย นอกเหนือจากไฟล์ดำเนินการทดสอบหลักแล้ว ตัวดำเนินการทดสอบจะต้องมีไฟล์ Manifest ของ runfiles ไฟล์อินพุตที่ควรพร้อมใช้งานสำหรับการทดสอบระหว่างรันไทม์ และอาจต้องมีข้อมูลเกี่ยวกับประเภท ขนาด และแท็กของการทดสอบ
ระบบบิลด์อาจใช้ Runfiles เพื่อส่งโค้ดและข้อมูล (ซึ่งอาจใช้ในการเพิ่มประสิทธิภาพเพื่อทำให้ไบนารีของการทดสอบแต่ละรายการมีขนาดเล็กลงโดยการแชร์ไฟล์ระหว่างการทดสอบ เช่น ผ่านการใช้ลิงก์แบบไดนามิก) ระบบบิลด์ควรตรวจสอบว่าไฟล์สั่งการที่สร้างขึ้นโหลดไฟล์เหล่านี้ผ่านอิมเมจ Runfiles ที่ให้ไว้โดยตัวดำเนินการทดสอบ ไม่ใช่การอ้างอิงตำแหน่งแบบสัมบูรณ์ในซอร์สหรือทรีเอาต์พุต
บทบาทของผู้ดำเนินการทดสอบ
จากมุมมองของผู้ทำการทดสอบ การทดสอบแต่ละรายการเป็นโปรแกรมที่เรียกใช้ได้ด้วย execve() อาจมีวิธีอื่นๆ ในการดำเนินการทดสอบ เช่น IDE อาจอนุญาตให้ดำเนินการทดสอบ Java ในระหว่างกระบวนการ อย่างไรก็ตาม ผลลัพธ์ของการทดสอบที่เป็นกระบวนการแบบสแตนด์อโลนจะต้องถือว่าเชื่อถือได้ หากกระบวนการทดสอบทำงานจนเสร็จสิ้นและสิ้นสุดลงตามปกติโดยมีรหัสการออกเป็น 0 หมายความว่าการทดสอบผ่านแล้ว ผลลัพธ์อื่นๆ จะถือว่าเป็นการทดสอบล้มเหลว โดยเฉพาะอย่างยิ่ง การเขียนสตริง PASS หรือ FAIL ไปยัง Stdout นั้นไม่มีความสำคัญใดๆ ต่อตัวดำเนินการทดสอบ
หากการทดสอบใช้เวลาดำเนินการนานเกินไป เกินขีดจำกัดทรัพยากรที่กำหนด หรือผู้ดำเนินการทดสอบตรวจพบพฤติกรรมต้องห้าม การดำเนินการดังกล่าวอาจเลือกหยุดการทดสอบและถือว่าการดำเนินการล้มเหลว นักวิ่งต้องไม่รายงานว่าผ่านการทดสอบหลังจากส่งสัญญาณไปยังกระบวนการทดสอบหรือเด็กผ่านกระบวนการทดสอบแล้ว
เป้าหมายการทดสอบทั้งหมด (ไม่ใช่แต่ละวิธีหรือการทดสอบแต่ละรายการ) จะมีเวลาจำกัดในการดำเนินการให้เสร็จสมบูรณ์ ขีดจำกัดเวลาสำหรับการทดสอบจะอิงตามแอตทริบิวต์ timeout ของการทดสอบในตารางต่อไปนี้
| เวลานอก | ขีดจำกัดเวลา (วินาที) |
|---|---|
| วิดีโอสั้น | 60 |
| ปานกลาง | 300 |
| long | 900 |
| นิรันดร์ | 3,600 |
การทดสอบที่ไม่ได้ระบุระยะหมดเวลาไว้อย่างชัดเจนจะแสดงแบบโดยนัยโดยอิงตาม size ของการทดสอบดังนี้
| ขนาด | ป้ายกำกับการหมดเวลาโดยนัย |
|---|---|
| เล็ก | วิดีโอสั้น |
| medium | ปานกลาง |
| ใหญ่ | long |
| มโหฬาร | นิรันดร์ |
การทดสอบ "ขนาดใหญ่" ที่ไม่มีการตั้งค่าระยะหมดเวลาอย่างชัดแจ้งจะได้รับการจัดสรรเวลา 900 วินาทีในการทำงาน การทดสอบ "ปานกลาง" ที่มีระยะหมดเวลาเป็น "สั้น" จะได้รับการจัดสรรเวลา 60 วินาที
นอกจากนี้ size ยังกำหนดการใช้งานสูงสุดของทรัพยากรอื่นๆ (เช่น RAM) เมื่อทำการทดสอบภายในเครื่อง ซึ่งต่างจาก timeout ตามที่อธิบายไว้ในคำจำกัดความทั่วไป
ชุดค่าผสมของป้ายกำกับ size และ timeout ทั้งหมดถูกกฎหมาย ดังนั้นจึงอาจมีการประกาศการทดสอบ "ขนาดใหญ่" ให้มีระยะหมดเวลาที่ "สั้น" คงจะทำเรื่องเลวร้ายๆ ขึ้นมาได้อย่างรวดเร็ว
การทดสอบอาจแสดงผลอย่างรวดเร็วเองโดยไม่คำนึงถึงระยะหมดเวลา การทดสอบไม่ได้ถูกลงโทษจากการหมดเวลาที่มากเกินไป แม้จะได้รับคำเตือนว่า โดยทั่วไปแล้วคุณควรตั้งค่าระยะหมดเวลาให้แน่นที่สุดเท่าที่จะทำได้โดยไม่ก่อให้เกิดความไม่สม่ำเสมอใดๆ
ลบล้างระยะหมดเวลาทดสอบได้ด้วยแฟล็กเบเซล --test_timeout ที่ทำงานด้วยตนเองภายใต้เงื่อนไขที่ทราบว่าช้า ค่า --test_timeout มีหน่วยเป็นวินาที ตัวอย่างเช่น --test_timeout=120 ตั้งค่าระยะหมดเวลาการทดสอบเป็น 2 นาที
นอกจากนี้ยังมีขอบเขตล่างที่แนะนำสำหรับระยะหมดเวลาในการทดสอบดังนี้
| เวลานอก | เวลาขั้นต่ำ (วินาที) |
|---|---|
| วิดีโอสั้น | 0 |
| ปานกลาง | 30 |
| long | 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 นักวิ่งใช้ข้อมูลนี้เพื่อเลือกการทดสอบที่จะเรียกใช้
เช่น การใช้กลยุทธ์แบบพบกันหมด ผู้ดำเนินการทดสอบบางคนไม่รองรับชาร์ดดิ้ง หากตัวเรียกใช้รองรับชาร์ดดิ้ง โปรแกรมเรียกใช้จะต้องสร้างหรืออัปเดตวันที่แก้ไขล่าสุดของไฟล์ที่ระบุโดย 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 |
เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ไฟล์นี้ควรใช้เพื่อรายงานความล้มเหลวที่เกิดจากโครงสร้างพื้นฐานของการทดสอบเท่านั้น ไม่ใช่เพื่อเป็นกลไกทั่วไปสำหรับการรายงานความล้มเหลวที่ไม่สม่ำเสมอของการทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานของการทดสอบหมายถึงระบบหรือไลบรารีที่ไม่ได้มีไว้สำหรับการทดสอบโดยเฉพาะ แต่อาจทำให้การทดสอบล้มเหลวจากการทำงานผิดพลาดได้ บรรทัดแรกคือชื่อของคอมโพเนนต์โครงสร้างพื้นฐานการทดสอบที่ทำให้เกิดความล้มเหลว บรรทัดแรกที่ 2 เป็นคำอธิบายความล้มเหลวที่มนุษย์อ่านได้ ระบบจะไม่ประมวลผลบรรทัดเพิ่มเติม) | ไม่บังคับ |
TEST_LOGSPLITTER_OUTPUT_FILE |
เส้นทางแบบสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้เพื่อเขียนบันทึก protobuffer ของ Loggingplitter) | ไม่บังคับ |
TEST_PREMATURE_EXIT_FILE |
เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้สำหรับการจับการเรียกไปยัง 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 |
ดัชนีชาร์ด (shard Index) ถ้าใช้ sharding |
ไม่บังคับ |
TEST_SHARD_STATUS_FILE |
เส้นทางไปยังไฟล์สำหรับแตะเพื่อระบุว่าการสนับสนุนสำหรับ sharding |
ไม่บังคับ |
TEST_SRCDIR |
เส้นทางสัมบูรณ์ไปยังฐานของโครงสร้าง Runfiles | จำเป็น |
TEST_TOTAL_SHARDS |
ทั้งหมด
shard count
หากใช้ sharding |
ไม่บังคับ |
TEST_TMPDIR |
เส้นทางแบบสัมบูรณ์ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ | จำเป็น |
TEST_WORKSPACE |
ชื่อพื้นที่ทำงานของที่เก็บในเครื่อง | ไม่บังคับ |
TEST_UNDECLARED_OUTPUTS_DIR |
เส้นทางสัมบูรณ์ไปยังไดเรกทอรีส่วนตัวที่เขียนได้ (ใช้ในการเขียนเอาต์พุตทดสอบที่ไม่ได้ประกาศ) ระบบจะบีบอัดไฟล์ที่เขียนไปยังไดเรกทอรี TEST_UNDECLARED_OUTPUTS_DIR ไว้และเพิ่มลงในไฟล์ 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
ไม่ได้ระบุรหัสกระบวนการปัจจุบัน รหัสกลุ่มกระบวนการ รหัสเซสชัน และรหัสกระบวนการระดับบนสุด กระบวนการนี้อาจเป็นผู้นำกลุ่มกระบวนการหรือผู้นำเซสชันหรือไม่ก็ได้ กระบวนการนี้อาจมีหรือไม่มีเทอร์มินัลควบคุม กระบวนการนี้อาจไม่มีโปรเซสย่อยใดทำงานอยู่เลยหรือมีโปรเซสย่อยที่ไม่มีการดำเนินการ กระบวนการนี้ไม่ควรมีเทรดหลายรายการเมื่อโค้ดทดสอบได้รับการควบคุม
ต้องเปิดตัวบ่งชี้ไฟล์ 0 (stdin) ให้อ่านได้ แต่จะไม่ระบุสิ่งที่แนบอยู่ การทดสอบจะต้องไม่อ่านจากการทดสอบ ตัวบอกไฟล์ 1 (stdout) และ 2
(stderr) ต้องเปิดให้เขียนได้ แต่จะไม่มีการระบุสิ่งที่แนบมาด้วย โดยอาจเป็นเทอร์มินัล, ไปป์, ไฟล์ปกติ หรือสิ่งอื่นๆ ที่จะเขียนอักขระได้ โดยอาจแชร์รายการในตารางไฟล์ที่เปิดอยู่ (หมายความว่าไม่สามารถค้นหาได้อย่างอิสระ) การทดสอบไม่ควรรับค่า
ข้อบ่งชี้ไฟล์อื่นๆ ที่เปิดอยู่
ค่าตั้งต้นจะเป็น 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 |
ไม่จำกัด หรือ 2044KB <= rlim <= 8192KB |
ไม่มีการระบุเวลาในการประมวลผลเริ่มต้น (ตามที่ times() ส่งคืน) และการใช้งานทรัพยากร (ตามที่ getrusage() แสดงผล)
ไม่ได้ระบุนโยบายการกำหนดเวลาเริ่มต้นและลำดับความสำคัญ
บทบาทของระบบโฮสต์
นอกเหนือจากบริบทของผู้ใช้ที่อยู่ภายใต้การควบคุมตัวดำเนินการทดสอบโดยตรงแล้ว ระบบปฏิบัติการที่ใช้ทดสอบจะต้องมีคุณสมบัติตรงตามพร็อพเพอร์ตี้บางรายการเพื่อให้การทดสอบใช้งานได้
ระบบไฟล์
ไดเรกทอรีรากที่การทดสอบสังเกตได้อาจเป็นหรือไม่ใช่ไดเรกทอรีรากจริงก็ได้
ต้องต่อเชื่อม /proc
เครื่องมือสร้างทั้งหมดจะแสดงอยู่ในเส้นทางสัมบูรณ์ของ /usr ซึ่งใช้โดยการติดตั้งภายใน
เส้นทางที่ขึ้นต้นด้วย /home อาจไม่พร้อมใช้งาน การทดสอบไม่ควรเข้าถึง
เส้นทางลักษณะดังกล่าว
/tmp ต้องเขียนได้ แต่การทดสอบควรหลีกเลี่ยงการใช้เส้นทางเหล่านี้
การทดสอบต้องไม่สันนิษฐานว่ามีเส้นทางคงที่ใดๆ ก็ตามที่พร้อมใช้งานสำหรับการใช้งานเฉพาะตัว
การทดสอบต้องไม่สันนิษฐานว่ามีการเปิดใช้ Atime กับระบบไฟล์ใดๆ ที่ต่อเชื่อม
ผู้ใช้และกลุ่ม
ต้องมีรูทผู้ใช้ ไม่มีผู้ใช้ และ unittest อยู่ รูทของกลุ่ม ไม่มีใคร และวิศวกร
การทดสอบต้องดำเนินการในฐานะผู้ใช้ที่ไม่ใช่ระดับรูท รหัสผู้ใช้จริงที่มีประสิทธิภาพต้องเท่ากัน และเช่นเดียวกันสำหรับรหัสกลุ่ม หลังจากนั้น จะไม่มีการระบุรหัสผู้ใช้ รหัสกลุ่ม ชื่อผู้ใช้ และชื่อกลุ่มปัจจุบัน ไม่ได้ระบุชุดรหัสกลุ่มเสริม
รหัสผู้ใช้และรหัสกลุ่มปัจจุบันต้องมีชื่อที่ตรงกันซึ่งดึงข้อมูลได้ด้วย getpwuid() และ getgrgid() ทั้งนี้ รหัสกลุ่มเสริมอาจไม่เหมือนกัน
ผู้ใช้ปัจจุบันต้องมีไดเรกทอรีหน้าแรก เนื่องจากอาจไม่สามารถเขียนได้ การทดสอบต้องไม่พยายามเขียน ไปยังข้อความทดสอบ
ระบบเครือข่าย
ไม่ได้ระบุชื่อโฮสต์ และอาจไม่มีจุดก็ได้ การแก้ไขชื่อโฮสต์ต้องระบุที่อยู่ IP ของโฮสต์ปัจจุบัน การแก้ไขชื่อโฮสต์ที่ตัดหลังจุดแรกก็ต้องได้ผลเช่นกัน ต้องแปลงชื่อโฮสต์ localhost
แหล่งข้อมูลอื่นๆ
การทดสอบจะได้รับ CPU อย่างน้อย 1 Core ฟังก์ชันอื่นๆ อาจมีให้ใช้ แต่เราไม่สามารถรับประกันได้ ไม่ได้ระบุแง่มุมด้านประสิทธิภาพอื่นๆ ของแกนนี้ คุณสามารถเพิ่มการจองให้มีจำนวนแกน 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 ตัวอย่างเช่น โดยทั่วไปแล้วคุณจะต้องสร้างซ็อกเก็ตภายใต้ /tmp เพื่อขีดจำกัดความยาวเส้นทางสำหรับซ็อกเก็ตโดเมน Unix Bazel จะติดตามไฟล์ดังกล่าวไม่ได้ ตัวการทดสอบเองต้องระวังอย่างไม่มีการเปลี่ยนแปลง เพื่อไม่ให้เกิดการชนกับไฟล์อื่น ทำการทดสอบและกระบวนการที่ไม่ใช่การทดสอบไปพร้อมๆ กัน รวมถึงล้างไฟล์ที่สร้างขึ้นใน /tmp
เฟรมเวิร์กการทดสอบที่ได้รับความนิยมบางรายการ เช่น JUnit4 TemporaryFolder หรือ Go TempDir ก็มีวิธีสร้างไดเรกทอรีชั่วคราวใน /tmp เป็นของตัวเอง เฟรมเวิร์กการทดสอบเหล่านี้มีฟังก์ชันที่ช่วยล้างไฟล์ใน /tmp คุณจึงใช้เฟรมเหล่านี้ได้แม้สร้างไฟล์ภายนอก TEST_TMPDIR ก็ตาม
การทดสอบต้องเข้าถึงอินพุตผ่านกลไก runfiles หรือส่วนอื่นๆ ของสภาพแวดล้อมการดำเนินการที่มีไว้โดยเฉพาะเพื่อทำให้ไฟล์อินพุตพร้อมใช้งาน
การทดสอบต้องไม่เข้าถึงเอาต์พุตอื่นๆ ของระบบบิลด์ที่เส้นทางที่อนุมานจากตำแหน่งของไฟล์ปฏิบัติการของตัวเอง
จะไม่มีการระบุว่าโครงสร้าง Runfiles ประกอบด้วยไฟล์ปกติ ลิงก์สัญลักษณ์ หรือไฟล์ผสม โครงสร้าง Runfiles อาจมีลิงก์สัญลักษณ์ไปยังไดเรกทอรี
การทดสอบควรหลีกเลี่ยงการใช้เส้นทางที่มีคอมโพเนนต์ .. ภายในแผนผัง Runfiles
ไม่ควรเขียนไดเรกทอรี ไฟล์ หรือลิงก์สัญลักษณ์ภายในแผนผัง Runfiles (รวมถึงเส้นทางข้ามสัญลักษณ์) ได้ (ซึ่งตามมาว่าไดเรกทอรี
ที่ใช้งานได้เริ่มต้นไม่ควรเขียนได้) การทดสอบต้องไม่สันนิษฐานว่าส่วนใดก็ตามของ Runfile ที่เขียนได้หรือเป็นของผู้ใช้ปัจจุบัน (เช่น chmod และ chgrp อาจไม่สำเร็จ)
โครงสร้าง Runfiles (รวมถึงเส้นทางที่ส่งผ่านลิงก์สัญลักษณ์) ต้องไม่เปลี่ยนแปลงระหว่างการดำเนินการทดสอบ ไดเรกทอรีระดับบนสุดและการต่อเชื่อมระบบไฟล์จะต้องไม่มีการเปลี่ยนแปลงใดๆ ซึ่งจะส่งผลต่อผลลัพธ์ของการค้นหาเส้นทางภายในแผนผัง Runfiles
การทดสอบอาจสร้างไฟล์ตามเส้นทางที่ TEST_PREMATURE_EXIT_FILE ระบุไว้เมื่อเริ่มต้นทำงาน และนำไฟล์ออกเมื่อออกเพื่อให้ควบคุมการออกได้เร็วขึ้น หาก Bazel เห็นไฟล์เมื่อการทดสอบเสร็จสิ้น ระบบจะถือว่าการทดสอบออกจากก่อนเวลาอันควรและทำเครื่องหมายว่าไม่ผ่าน
รูปแบบแท็ก
แท็กบางรายการในกฎการทดสอบจะมีความหมายพิเศษ ดูสารานุกรมการสร้างบาเซลในแอตทริบิวต์ tags เพิ่มเติม
| ติดแท็ก | ความหมาย |
|---|---|
exclusive |
ไม่มีการทดสอบอื่นๆ ในเวลาเดียวกัน |
external |
การทดสอบมีการขึ้นต่อกันภายนอก ปิดใช้การแคชการทดสอบ |
large |
test_suite แบบแผน ชุดการทดสอบขนาดใหญ่ |
manual * |
ไม่รวมเป้าหมายการทดสอบในรูปแบบเป้าหมายไวลด์การ์ด เช่น :..., :* หรือ :all |
medium |
แบบแผน test_suite ชุดการทดสอบปานกลาง |
small |
test_suite แบบแผน ชุดการทดสอบขนาดเล็ก |
smoke |
test_suite ซึ่งหมายความว่าควรเรียกใช้ก่อนที่จะคอมมิตการเปลี่ยนแปลงโค้ดลงในระบบควบคุมเวอร์ชัน |
Runfiles
ในตัวอย่างต่อไปนี้ สมมติว่ามีกฎ *_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() หรือทรัพยากร Dependency ของเวลาคอมไพล์หรือรันไทม์ใดๆ ก็ตาม การแก้ไขไฟล์ต้นฉบับไม่มีผลต่อโครงสร้างของไดเรกทอรี Runfiles จึงไม่ทริกเกอร์การสร้างใหม่ใดๆ
เนื้อหา
ไดเรกทอรี Runfiles ประกอบด้วยข้อมูลต่อไปนี้
- Symlinks กับทรัพยากร Dependency ของรันไทม์: ExportFile และ CommandRule แต่ละรายการที่เป็นทรัพยากร Dependency ขณะรันไทม์ของกฎ
*_binary()จะแสดงด้วยลิงก์สัญลักษณ์เดียวในไดเรกทอรี Runfiles ชื่อของลิงก์สัญลักษณ์คือ$(WORKSPACE)/package_name/rule_nameตัวอย่างเช่น symlink สำหรับเซิร์ฟเวอร์ จะมีชื่อว่า$(WORKSPACE)/deps/server/serverและเส้นทางแบบเต็มจะเป็น$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverปลายทางของลิงก์สัญลักษณ์คือ ExportFileName() ของ ExportFile หรือ CommandRule ซึ่งแสดงเป็นเส้นทางสัมบูรณ์ ดังนั้น ปลายทางของลิงก์สัญลักษณ์อาจเป็น$(WORKSPACE)/linux-dbg/deps/server/42/server - ลิงก์สัญลักษณ์ไปยังไฟล์ย่อย: ทุกๆ
*_binary()Z ซึ่งขึ้นต่อกันตามรันไทม์ของ*_binary()C จะมีลิงก์ที่ 2 ในไดเรกทอรี Runfiles ของ C ไปยัง Runfiles ของ Z ชื่อของลิงก์สัญลักษณ์คือ$(WORKSPACE)/package_name/rule_name.runfilesเป้าหมายของ symlink คือ ไดเรกทอรี runfiles ตัวอย่างเช่น โปรแกรมย่อยทั้งหมดจะใช้ไดเรกทอรี Runfiles ร่วมกัน