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

Nightly · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

ฉากหลัง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ปัจจุบันระบบยังไม่ได้บังคับใช้พฤติกรรมดังกล่าว อย่างไรก็ตาม โปรแกรมเรียกใช้การทดสอบขอสงวนสิทธิ์ ในการเพิ่มการบังคับใช้ดังกล่าวในอนาคต

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

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

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

บทบาทของโปรแกรมเรียกใช้การทดสอบ

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

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

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

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

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

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

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

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

การผสมป้ายกำกับ size และ timeout ทั้งหมดเป็นไปตามกฎหมาย ดังนั้นการทดสอบที่ "นานมาก" อาจประกาศว่ามีระยะหมดเวลาเป็น "สั้น" ซึ่งคาดว่ามันจะทำสิ่งที่ น่ากลัวมากๆ ได้อย่างรวดเร็ว

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

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

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

เวลานอก เวลาขั้นต่ำ (วินาที)
วิดีโอสั้น 0
ปานกลาง 30
ยาว 300
นิรันดร์ 900

เช่น หากการทดสอบ "ปานกลาง" เสร็จสมบูรณ์ใน 5.5 วินาที ให้ลองตั้งค่า timeout = "short" หรือ size = "small" การใช้--test_verbose_timeout_warnings ตัวเลือกบรรทัดคำสั่งของ Bazel จะแสดงการทดสอบที่มีขนาดที่ระบุใหญ่เกินไป

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

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

การแบ่งพาร์ติชันการทดสอบ

คุณสามารถทำการทดสอบแบบขนานได้ผ่านการแบ่งการทดสอบ ดู --test_sharding_strategy และ shard_count เพื่อ เปิดใช้การแบ่งพาร์ติชันการทดสอบ เมื่อเปิดใช้การแยกส่วน ระบบจะเปิดใช้โปรแกรมเรียกใช้การทดสอบ 1 ครั้ง ต่อส่วน ตัวแปรสภาพแวดล้อม TEST_TOTAL_SHARDS คือจำนวน Shard และ TEST_SHARD_INDEX คือ ดัชนี Shard โดยเริ่มที่ 0 ผู้เรียกใช้จะใช้ข้อมูลนี้เพื่อเลือกการทดสอบที่จะเรียกใช้ เช่น ใช้กลยุทธ์แบบหมุนเวียน โปรแกรมเรียกใช้การทดสอบบางตัวไม่รองรับ การแบ่งพาร์ติชัน หากโปรแกรมเรียกใช้รองรับการแบ่งพาร์ติชัน จะต้องสร้างหรืออัปเดตวันที่แก้ไขล่าสุดของไฟล์ที่ระบุโดย TEST_SHARD_STATUS_FILE ไม่เช่นนั้น Bazel จะทดสอบไม่สำเร็จหากมีการแบ่งพาร์ติชัน

เงื่อนไขเริ่มต้น

เมื่อทำการทดสอบ โปรแกรมเรียกใช้การทดสอบต้องสร้างเงื่อนไขเริ่มต้นบางอย่าง

โปรแกรมเรียกใช้การทดสอบต้องเรียกใช้การทดสอบแต่ละรายการด้วยเส้นทางไปยังไฟล์ปฏิบัติการทดสอบใน argv[0] เส้นทางนี้ต้องเป็นเส้นทางแบบสัมพัทธ์และอยู่ใต้ไดเรกทอรีปัจจุบันของเทสต์ (ซึ่งอยู่ในทรีไฟล์ที่รันได้ โปรดดูด้านล่าง) โปรแกรมเรียกใช้การทดสอบไม่ควรส่งอาร์กิวเมนต์อื่นๆ ไปยังการทดสอบ เว้นแต่ผู้ใช้จะขออย่างชัดเจน

บล็อกสภาพแวดล้อมเริ่มต้นควรประกอบด้วยข้อมูลต่อไปนี้

ตัวแปร ค่า สถานะ
HOME ค่าของ $TEST_TMPDIR แนะนำ
LANG unset ต้องระบุ
LANGUAGE unset ต้องระบุ
LC_ALL unset ต้องระบุ
LC_COLLATE unset ต้องระบุ
LC_CTYPE unset หรือ C.UTF-8 ต้องระบุ
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 เส้นทางแบบสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ควรใช้ไฟล์นี้ เพื่อรายงานความล้มเหลวที่เกิดจากโครงสร้างพื้นฐานในการทดสอบเท่านั้น ไม่ใช่กลไกทั่วไปในการรายงานความล้มเหลวที่ไม่เสถียรของ การทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานในการทดสอบหมายถึงระบบ หรือไลบรารีที่ไม่ได้เฉพาะเจาะจงสำหรับการทดสอบ แต่สามารถทำให้การทดสอบล้มเหลวได้ เนื่องจากทำงานผิดปกติ บรรทัดแรกคือชื่อของคอมโพเนนต์โครงสร้างพื้นฐานการทดสอบ ที่ทำให้เกิดความล้มเหลว ส่วนบรรทัดที่ 2 คือคำอธิบายที่มนุษย์อ่านได้ ของความล้มเหลว ระบบจะไม่สนใจบรรทัดเพิ่มเติม) ไม่บังคับ
TEST_LOGSPLITTER_OUTPUT_FILE เส้นทางสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ใช้เพื่อเขียน บันทึก Logsplitter protobuffer) ไม่บังคับ
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 หากใช้ sharding ไม่บังคับ
TEST_SHARD_STATUS_FILE เส้นทางไปยังไฟล์ที่จะแตะเพื่อระบุการรองรับ sharding ไม่บังคับ
TEST_SRCDIR เส้นทางสัมบูรณ์ไปยังฐานของทรีไฟล์ที่เรียกใช้ ต้องระบุ
TEST_TOTAL_SHARDS total shard count, if sharding is used ไม่บังคับ
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

รหัสกระบวนการปัจจุบัน รหัสกลุ่มกระบวนการ รหัสเซสชัน และรหัสกระบวนการหลักไม่ได้ระบุ กระบวนการอาจเป็นหรือไม่เป็นผู้นำกลุ่มกระบวนการหรือผู้นำเซสชันก็ได้ กระบวนการอาจมีหรือไม่มีเทอร์มินัลควบคุมก็ได้ กระบวนการอาจมีกระบวนการย่อยที่ทำงานอยู่หรือยังไม่ได้เก็บเกี่ยวอย่างน้อย 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 ไม่จำกัด หรือ 2044KB <= rlim <= 8192KB

เวลาในการประมวลผลเริ่มต้น (ตามที่ times() แสดง) และการใช้ทรัพยากร (ตามที่ getrusage() แสดง) ไม่ได้ระบุไว้

ไม่ได้ระบุนโยบายการจัดตารางเวลาและลำดับความสำคัญเริ่มต้น

บทบาทของระบบโฮสต์

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

ระบบไฟล์

ไดเรกทอรีรากที่การทดสอบสังเกตอาจเป็นหรือไม่เป็นไดเรกทอรีรากจริงก็ได้

ต้องติดตั้ง /proc

เครื่องมือบิลด์ทั้งหมดต้องอยู่ที่เส้นทางสมบูรณ์ภายใต้ /usr ที่ใช้โดยการติดตั้งในเครื่อง

เส้นทางที่ขึ้นต้นด้วย /home อาจไม่พร้อมใช้งาน การทดสอบไม่ควรเข้าถึงเส้นทางดังกล่าว

/tmp ควรเขียนได้ แต่การทดสอบควรหลีกเลี่ยงการใช้เส้นทางเหล่านี้

การทดสอบต้องไม่ถือว่ามีเส้นทางคงที่สำหรับการใช้งานเฉพาะ

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

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

ต้องมีผู้ใช้ root, nobody และ unittest ต้องมีกลุ่ม root, nobody และ eng

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

รหัสผู้ใช้และรหัสกลุ่มปัจจุบันต้องมีชื่อที่สอดคล้องกันซึ่งสามารถเรียกข้อมูลได้ด้วย 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 เช่น ขีดจํากัดความยาวเส้นทางสําหรับซ็อกเก็ตโดเมน Unix มักจะต้องสร้างซ็อกเก็ตภายใต้ /tmp Bazel จะติดตามไฟล์ดังกล่าวไม่ได้ การทดสอบเองต้องดูแลให้เป็นแบบเฮอร์มิติก ใช้เส้นทางที่ไม่ซ้ำกันเพื่อหลีกเลี่ยงการชนกับกระบวนการทดสอบและกระบวนการที่ไม่ใช่การทดสอบอื่นๆ ที่ทำงานพร้อมกัน และล้างไฟล์ที่สร้างขึ้นใน /tmp

เฟรมเวิร์กการทดสอบยอดนิยมบางรายการ เช่น JUnit4 TemporaryFolder หรือ Go TempDir มี วิธีสร้างไดเรกทอรีชั่วคราวภายใต้ /tmp เป็นของตัวเอง เฟรมเวิร์กการทดสอบเหล่านี้ มีฟังก์ชันการทำงานที่ล้างไฟล์ใน /tmp คุณจึงใช้ เฟรมเวิร์กเหล่านี้ได้แม้ว่าจะสร้างไฟล์นอก TEST_TMPDIR

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

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

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

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

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

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

แพลตฟอร์มการดำเนินการ

แพลตฟอร์มการดำเนินการสำหรับการดำเนินการทดสอบจะกำหนดผ่านการแก้ปัญหา Toolchain เช่นเดียวกับการดำเนินการอื่นๆ กฎการทดสอบแต่ละข้อมี testกลุ่ม exec ที่กำหนดไว้โดยนัย ซึ่ง หากไม่มีการลบล้าง จะมีข้อกำหนดเกี่ยวกับเครื่องมือที่จำเป็นใน @bazel_tools//tools/test:default_test_toolchain_type

Toolchain ประเภทนี้ไม่มีข้อมูลใดๆ ในรูปแบบของผู้ให้บริการ แต่สามารถใช้เพื่อมีอิทธิพลต่อแพลตฟอร์มการดำเนินการของการทดสอบได้

Bazel จะลงทะเบียน Toolchain ดังกล่าว 2 รายการ ซึ่งจะมีผลหากผู้ใช้ไม่ได้ กำหนด Toolchain ของตนเองอย่างชัดเจน::

  • หาก--@bazel_tools//tools/test:incompatible_use_default_test_toolchainเปิดใช้ (ค่าเริ่มต้น) ชุดเครื่องมือทดสอบที่ใช้งานอยู่จะเป็น @bazel_tools//tools/test:default_test_toolchain เครื่องมือนี้ต้องมี แพลตฟอร์มการดำเนินการที่ตรงกับข้อจำกัดของแพลตฟอร์มเป้าหมายของกฎการทดสอบทั้งหมด

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

  • หากปิดใช้ --@bazel_tools//tools/test:incompatible_use_default_test_toolchain เชนเครื่องมือทดสอบที่ใช้งานอยู่จะเป็น @bazel_tools//tools/test:legacy_test_toolchain Toolchain นี้ไม่ได้ กำหนดข้อจำกัดใดๆ ดังนั้นการดำเนินการทดสอบที่ไม่มีข้อจำกัด exec ที่ระบุด้วยตนเอง จะได้รับการกำหนดค่าสำหรับแพลตฟอร์มการดำเนินการที่ลงทะเบียนเป็นแพลตฟอร์มแรก

    ซึ่งมักจะไม่ใช่ลักษณะการทำงานที่ต้องการในการสร้างหลายแพลตฟอร์ม เนื่องจากอาจส่งผลให้ เช่น ไบนารีทดสอบที่สร้างขึ้นสำหรับ Linux ในเครื่อง Windows ทำงานบน Windows

    เนื่องจากการตั้งค่านี้เป็นแบบเดิม ตัวเลือกนี้จึงอาจไม่พร้อมใช้งานใน Bazel รุ่นต่อๆ ไป

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

การตั้งชื่อแท็ก

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

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

Runfiles

ในส่วนต่อไปนี้ ให้ถือว่ามีกฎ *_binary() ที่ติดป้ายกำกับ //foo/bar:unittest ซึ่งมีทรัพยากร Dependency รันไทม์ในกฎที่ติดป้ายกำกับ //deps/server:server

ตำแหน่ง

ไดเรกทอรี Runfiles สำหรับเป้าหมาย //foo/bar:unittest คือไดเรกทอรี $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles เส้นทางนี้เรียกว่าrunfiles_dir

แท็กเริ่มการทำงาน

ระบบจะประกาศไดเรกทอรี runfiles เป็นทรัพยากร Dependency ในเวลาคอมไพล์ของกฎ *_binary() ส่วนไดเรกทอรีไฟล์ที่เรียกใช้ได้จะขึ้นอยู่กับชุดไฟล์ BUILD ที่ส่งผลต่อกฎ *_binary() หรือการขึ้นต่อกันในเวลาคอมไพล์หรือรันไทม์ การแก้ไขไฟล์ต้นฉบับจะไม่ส่งผลต่อโครงสร้างของ ไดเรกทอรี runfiles จึงไม่ทริกเกอร์การสร้างใหม่

เนื้อหา

ไดเรกทอรีไฟล์ที่เรียกใช้จะมีข้อมูลต่อไปนี้

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