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

รายงานปัญหา ดูแหล่งที่มา Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

ฉากหลัง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตัวแปร ค่า สถานะ
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 เส้นทางแบบสัมบูรณ์ไปยังไฟล์ส่วนตัวในไดเรกทอรีที่เขียนได้ (ควรใช้ไฟล์นี้ เพื่อรายงานความล้มเหลวที่เกิดจากโครงสร้างพื้นฐานในการทดสอบเท่านั้น ไม่ใช่กลไกทั่วไปในการรายงานความล้มเหลวที่ไม่เสถียรของ การทดสอบ ในบริบทนี้ โครงสร้างพื้นฐานในการทดสอบหมายถึงระบบ หรือไลบรารีที่ไม่ได้เฉพาะเจาะจงสำหรับการทดสอบ แต่สามารถทำให้การทดสอบล้มเหลวได้ เนื่องจากทำงานผิดปกติ บรรทัดแรกคือชื่อของคอมโพเนนต์โครงสร้างพื้นฐานการทดสอบ ที่ทำให้เกิดความล้มเหลว ส่วนบรรทัดที่ 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 เกี่ยวกับแอตทริบิวต์ tags ด้วย

แท็ก ความหมาย
exclusive อย่าทำการทดสอบอื่นพร้อมกัน
external test มีทรัพยากร 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

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

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

เนื้อหา

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

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