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

รายงานปัญหา ดูแหล่งที่มา /3} /4} {3/4} {3/4} {3/4} {3/4} /4.

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

ที่มา

ภาษา 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 เช่น โปรแกรมย่อยทั้งหมดจะแชร์ไดเรกทอรีการเรียกใช้ไฟล์ทั่วไป