Thử nghiệm bách khoa toàn thư

Báo cáo vấn đề Xem nguồn Hằng đêm · 7.3 · 7.2 · 7.1 · 7 · 6,5

Bản đặc tả đầy đủ về môi trường thực thi kiểm thử.

Thông tin khái quát

Ngôn ngữ Bazel BUILD bao gồm các quy tắc có thể được sử dụng để xác định tự động các chương trình kiểm tra bằng nhiều ngôn ngữ.

Các hoạt động kiểm thử được chạy bằng bazel test.

Người dùng cũng có thể trực tiếp thực thi các tệp nhị phân kiểm thử. Điều này được cho phép nhưng không được chứng thực, do lời gọi hành động này sẽ không tuân thủ các uỷ nhiệm được mô tả dưới đây.

Các bài kiểm thử phải có tính ẩn: tức là chúng chỉ nên truy cập vào các tài nguyên đó mà chúng có phần phụ thuộc được khai báo. Nếu xét nghiệm không đúng cách kín thì chúng sẽ không cho kết quả có thể lặp lại trước đây. Đây có thể là vấn đề quan trọng đối với việc tìm ra thủ phạm (xác định thay đổi nào làm hỏng thử nghiệm), phát hành khả năng kiểm tra kỹ thuật và cô lập tài nguyên của các bài kiểm thử (tự động hoá các khung kiểm thử không nên dùng DDOS trên một máy chủ vì một số thử nghiệm có giao tiếp với nó).

Mục tiêu

Mục tiêu của trang này là chính thức thiết lập môi trường thời gian chạy cho và hành vi dự kiến của kiểm thử Bazel. Quy tắc này cũng đặt ra các yêu cầu đối với thử nghiệm Runner và hệ thống xây dựng.

Thông số kỹ thuật của môi trường kiểm thử giúp tác giả kiểm thử tránh phụ thuộc vào hành vi không xác định và do đó mang lại cho cơ sở hạ tầng kiểm thử nhiều quyền tự do hơn thực hiện các thay đổi về phương thức triển khai. Thông số kỹ thuật bổ sung một số lỗ hổng hiện cho phép nhiều kiểm thử có thể vượt qua mặc dù không được cô lập đúng cách, thuật toán tất định và biến thiên.

Trang này nhằm mục đích cung cấp kiến thức vừa có tính chuẩn mực, vừa có căn cứ đáng tin. Nếu trường hợp này quy cách và hành vi được triển khai của trình chạy kiểm thử không đồng ý, quy cách sẽ được ưu tiên.

Thông số kỹ thuật được đề xuất

Các từ khóa "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SÁNG", "KHÔNG ĐƯỢC", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" sẽ được hiểu là được mô tả trong RFC 2119 của IETF.

Mục đích của kiểm thử

Mục đích của kiểm thử Bazel là xác nhận một số thuộc tính của các tệp nguồn đã kiểm tra kho lưu trữ. (Trên trang này, "tệp nguồn" bao gồm dữ liệu thử nghiệm, đầu ra vàng và mọi thứ khác được quản lý phiên bản). Một người dùng viết một để xác nhận một bất biến mà chúng muốn duy trì. Người dùng khác thực thi kiểm thử sau để kiểm tra xem giá trị bất biến có bị hỏng hay không. Nếu kiểm thử phụ thuộc vào bất kỳ biến nào khác ngoài tệp nguồn (không kín), giá trị của nó sẽ giảm đi, bởi vì người dùng sau này không thể chắc chắn những thay đổi của họ là do lỗi khi bài kiểm thử ngừng vượt qua.

Do đó, kết quả kiểm thử chỉ được phụ thuộc vào:

  • tệp nguồn mà bài kiểm thử có phần phụ thuộc được khai báo
  • sản phẩm của hệ thống xây dựng mà bài kiểm thử có phần phụ thuộc được khai báo
  • các tài nguyên có hành vi được trình chạy kiểm thử đảm bảo là không đổi

Hiện tại, chúng tôi không thực thi hành vi như vậy. Tuy nhiên, trình chạy kiểm thử đặt trước chúng tôi sẽ có thêm biện pháp thực thi như vậy trong tương lai.

Vai trò của hệ thống xây dựng

Các quy tắc kiểm thử tương tự như các quy tắc nhị phân trong đó mỗi quy tắc phải mang lại một tệp thực thi . Đối với một số ngôn ngữ, đây là chương trình giả lập kết hợp khai thác dành riêng cho ngôn ngữ với mã kiểm thử. Quy tắc kiểm thử phải tạo ra các phiên bản khác đầu ra tương ứng. Ngoài tệp thực thi kiểm thử chính, trình chạy kiểm thử sẽ cần một tệp kê khai runfiles, tức là các tệp đầu vào cần được cung cấp vào bài kiểm thử trong thời gian chạy và có thể cần thông tin về loại, kích thước và của thử nghiệm.

Hệ thống xây dựng có thể sử dụng các tệp run để phân phối mã cũng như dữ liệu. (Kết quả này có thể được dùng làm phương pháp tối ưu hoá để làm nhỏ từng tệp nhị phân kiểm thử bằng cách chia sẻ giữa các thử nghiệm, chẳng hạn như thông qua việc sử dụng liên kết động). Hệ thống xây dựng phải đảm bảo rằng các tệp thực thi được tạo sẽ tải các tệp này thông qua các tệp chạy hình ảnh do trình chạy kiểm thử cung cấp, thay vì tham chiếu được cố định giá trị trong mã đến giá trị tuyệt đối vị trí trong cây nguồn hoặc cây đầu ra.

Vai trò của trình chạy kiểm thử

Từ góc độ của trình chạy kiểm thử, mỗi bài kiểm thử là một chương trình có thể được gọi bằng execve(). Có thể có những cách khác để thực thi kiểm thử; ví dụ: IDE có thể cho phép thực thi các kiểm thử Java trong quá trình. Tuy nhiên, kết quả việc chạy thử nghiệm như một quy trình độc lập phải được coi là có căn cứ đáng tin. Nếu một quy trình kiểm thử chạy đến khi hoàn tất và kết thúc như bình thường bằng mã thoát là 0, đoạn mã kiểm thử đã thành công. Mọi kết quả khác đều được coi là không thành công kiểm thử. Trong cụ thể, việc viết bất kỳ chuỗi nào PASS hoặc FAIL vào stdout không có có ý nghĩa quan trọng đối với trình chạy kiểm thử.

Nếu kiểm thử mất quá nhiều thời gian để thực thi, vượt quá một giới hạn tài nguyên nào đó hoặc bài kiểm thử Nếu phát hiện hành vi bị cấm, Runner có thể chọn tắt chương trình kiểm thử và coi quá trình chạy là lỗi. Trình chạy không được báo cáo kiểm thử là đạt sau gửi tín hiệu đến quá trình kiểm thử hoặc bất kỳ phần tử con nào trong quá trình đó.

Toàn bộ mục tiêu kiểm thử (không phải từng phương thức hoặc hoạt động kiểm thử riêng lẻ) sẽ chỉ có một thời gian chạy cho đến khi hoàn tất. Giới hạn thời gian cho thử nghiệm dựa trên timeout theo vào bảng sau:

tạm ngừng Giới hạn thời gian (giây)
ngắn 60
trung bình 300
long 900
vĩnh cửu 3600

Các thử nghiệm không chỉ định rõ thời gian chờ có một thời gian được ngụ ý dựa trên size của kiểm thử như sau:

size Nhãn thời gian chờ ngụ ý
nhỏ ngắn
trung bình trung bình
lớn long
to lớn vĩnh cửu

Một "lớn" chương trình kiểm thử không có cài đặt thời gian chờ rõ ràng sẽ được phân bổ 900 giây để chạy. Một "phương tiện" thử nghiệm với thời gian chờ là "ngắn" sẽ được phân bổ 60 giây.

Không giống như timeout, size còn xác định thêm mức sử dụng cao nhất giả định các tài nguyên khác (như RAM) khi chạy kiểm thử cục bộ, như được mô tả trong Định nghĩa phổ biến.

Tất cả các cách kết hợp nhãn size và timeout đều hợp pháp, vì vậy, số lượng nhãn là "rất lớn" thử nghiệm có thể được khai báo là có thời gian chờ "ngắn". Có lẽ nó thực sự sẽ làm một số việc một cách nhanh chóng.

Các bài kiểm thử có thể trả về nhanh tuỳ ý bất kể hết thời gian chờ. Một bài kiểm tra không bị phạt cho thời gian chờ quá mức, mặc dù hệ thống có thể đưa ra cảnh báo: bạn nên thường đặt thời gian chờ của bạn ở mức tối đa mà không làm phát sinh bất kỳ sự cố nào.

Bạn có thể ghi đè thời gian chờ kiểm thử bằng cờ bazel --test_timeout khi chạy theo cách thủ công trong những điều kiện được biết là chậm. Chiến lược phát hành đĩa đơn Giá trị của --test_timeout được tính bằng giây. Ví dụ: --test_timeout=120 đặt thời gian chờ kiểm thử thành 2 phút.

Ngoài ra, bạn nên áp dụng giới hạn dưới cho thời gian chờ kiểm thử như sau:

tạm ngừng Thời gian tối thiểu (giây)
ngắn 0
trung bình 30
long 300
vĩnh cửu 900

Ví dụ: nếu "vừa phải" kiểm thử hoàn tất trong 5,5 giây, hãy cân nhắc đặt timeout = "short" hoặc size = "small". Sử dụng bazel --test_verbose_timeout_warnings tuỳ chọn dòng lệnh sẽ hiển thị các bài kiểm thử có kích thước được chỉ định quá lớn.

Kích thước kiểm thử và thời gian chờ được chỉ định trong tệp BUILD theo tại đây. Nếu chưa chỉ định, quy mô của thử nghiệm sẽ được đặt mặc định là "trung bình".

Nếu quy trình chính của kiểm thử thoát ra, nhưng một số phần tử con của quy trình này vẫn đang chạy, trình chạy kiểm thử nên xem lần chạy đó là hoàn tất và coi đó là một thành công hoặc dựa trên mã thoát quan sát được từ quá trình chính. Trình chạy kiểm thử có thể tắt mọi quá trình không mong muốn. Kiểm thử không được làm rò rỉ các quy trình theo cách này.

Phân đoạn kiểm thử

Bạn có thể chạy song song các hoạt động kiểm thử thông qua tính năng phân đoạn kiểm thử. Xem --test_sharding_strategy và shard_count để bật tính năng phân đoạn kiểm thử. Khi bật tính năng phân đoạn, trình chạy kiểm thử sẽ được khởi chạy một lần cho mỗi phân đoạn. Biến môi trường TEST_TOTAL_SHARDS là số phân đoạn và TEST_SHARD_INDEX là phân đoạn chỉ mục phân đoạn, bắt đầu từ 0. Người chạy chương trình sử dụng thông tin này để chọn loại kiểm thử để chạy – ví dụ: sử dụng chiến lược vòng tròn. Không phải trình chạy kiểm thử nào cũng hỗ trợ phân đoạn. Nếu hỗ trợ tính năng phân đoạn, thì trình chạy phải tạo hoặc cập nhật ngày sửa đổi của tệp được chỉ định bởi TEST_SHARD_STATUS_FILE. Ngược lại, nếu --incompatible_check_sharding_support được bật, Bazel sẽ không vượt qua kiểm thử nếu được phân đoạn.

Điều kiện ban đầu

Khi thực thi một chương trình kiểm thử, trình chạy kiểm thử phải thiết lập một số lệnh bắt đầu .

Trình chạy kiểm thử phải gọi từng hoạt động kiểm thử bằng đường dẫn đến tệp thực thi kiểm thử trong argv[0]. Đường dẫn này phải là đường dẫn tương đối và nằm dưới thư mục hiện tại của kiểm thử (nằm trong cây runfile, hãy xem bên dưới). Trình chạy kiểm thử không được truyền bất kỳ các đối số khác cho chương trình kiểm thử trừ phi người dùng yêu cầu rõ ràng.

Khối môi trường ban đầu sẽ bao gồm như sau:

Biến Giá trị Trạng thái
HOME giá trị của $TEST_TMPDIR được đề nghị
LANG huỷ đặt bắt buộc
LANGUAGE huỷ đặt bắt buộc
LC_ALL huỷ đặt bắt buộc
LC_COLLATE huỷ đặt bắt buộc
LC_CTYPE huỷ đặt bắt buộc
LC_MESSAGES huỷ đặt bắt buộc
LC_MONETARY huỷ đặt bắt buộc
LC_NUMERIC huỷ đặt bắt buộc
LC_TIME huỷ đặt bắt buộc
LD_LIBRARY_PATH danh sách các thư mục được phân tách bằng dấu hai chấm chứa thư viện dùng chung tùy chọn
JAVA_RUNFILES giá trị của $TEST_SRCDIR không dùng nữa
LOGNAME giá trị của $USER bắt buộc
PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. được đề nghị
PWD $TEST_SRCDIR/workspace-name được đề nghị
SHLVL 2 được đề nghị
TEST_INFRASTRUCTURE_FAILURE_FILE đường dẫn tuyệt đối đến một tệp riêng tư trong thư mục có thể ghi (Tệp này chỉ nên dùng để báo cáo các lỗi bắt nguồn từ quá trình kiểm thử cơ sở hạ tầng, không phải như một cơ chế chung để báo cáo các lỗi không ổn định kiểm thử. Trong bối cảnh này, cơ sở hạ tầng kiểm thử được định nghĩa là các hệ thống hoặc thư viện không dành riêng cho kiểm thử nhưng có thể gây ra thất bại trong kiểm thử do sự cố. Dòng đầu tiên là tên của cơ sở hạ tầng kiểm thử thành phần gây ra lỗi, thành phần thứ hai là thành phần mà con người có thể đọc được mô tả lỗi. Các dòng bổ sung sẽ bị bỏ qua.) tùy chọn
TEST_LOGSPLITTER_OUTPUT_FILE đường dẫn tuyệt đối đến một tệp riêng tư trong thư mục có thể ghi (dùng để ghi Nhật ký bộ đệm protSplitter để chia) tùy chọn
TEST_PREMATURE_EXIT_FILE đường dẫn tuyệt đối đến một tệp riêng tư trong thư mục có thể ghi (dùng cho đang bắt cuộc gọi đến exit()) tùy chọn
TEST_RANDOM_SEED Nếu tuỳ chọn --runs_per_test được sử dụng, TEST_RANDOM_SEED được đặt thành run number (bắt đầu bằng 1) cho mỗi lần chạy kiểm thử riêng lẻ. tùy chọn
TEST_RUN_NUMBER Nếu tuỳ chọn --runs_per_test được sử dụng, TEST_RUN_NUMBER được đặt thành run number (bắt đầu bằng 1) cho mỗi lần chạy kiểm thử riêng lẻ. tùy chọn
TEST_TARGET Tên của mục tiêu đang được thử nghiệm tùy chọn
TEST_SIZE Thử nghiệm size tùy chọn
TEST_TIMEOUT Thử nghiệm timeout trong vài giây tùy chọn
TEST_SHARD_INDEX chỉ mục phân đoạn, nếu sharding được sử dụng tùy chọn
TEST_SHARD_STATUS_FILE đường dẫn đến tệp sẽ chạm vào để cho biết có hỗ trợ sharding tùy chọn
TEST_SRCDIR đường dẫn tuyệt đối đến gốc của cây runfile bắt buộc
TEST_TOTAL_SHARDS tổng shard count! nếu sharding được sử dụng tùy chọn
TEST_TMPDIR đường dẫn tuyệt đối đến thư mục riêng có thể ghi bắt buộc
TEST_WORKSPACE tên không gian làm việc của kho lưu trữ cục bộ tùy chọn
TEST_UNDECLARED_OUTPUTS_DIR đường dẫn tuyệt đối đến thư mục riêng có thể ghi (dùng để ghi các thư mục chưa được khai báo kết quả kiểm thử). Bất kỳ tệp nào được ghi vào Thư mục TEST_UNDECLARED_OUTPUTS_DIR sẽ được nén và đã thêm vào tệp outputs.zip trong bazel-testlogs. tùy chọn
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR đường dẫn tuyệt đối đến thư mục riêng có thể ghi (dùng để ghi các thư mục chưa được khai báo kiểm thử chú thích đầu ra tệp .part và .pb). tùy chọn
TEST_WARNINGS_OUTPUT_FILE đường dẫn tuyệt đối đến một tệp riêng tư trong thư mục có thể ghi (dùng để ghi cảnh báo về mục tiêu thử nghiệm) tùy chọn
TESTBRIDGE_TEST_ONLY giá trị của --test_filter! nếu được chỉ định tùy chọn
TZ UTC bắt buộc
USER giá trị của getpwuid(getuid())->pw_name bắt buộc
XML_OUTPUT_FILE Vị trí mà hành động kiểm thử cần ghi tệp đầu ra XML cho kết quả kiểm thử. Nếu không, Bazel sẽ tạo một tệp đầu ra XML mặc định để gói nhật ký kiểm thử như một phần của hành động thử nghiệm. Lược đồ XML dựa trên Giản đồ kết quả kiểm thử JUnit. tùy chọn
BAZEL_TEST Cho biết tệp thực thi kiểm thử đang được bazel test thúc đẩy bắt buộc

Môi trường có thể chứa các mục nhập khác. Kiểm thử không nên phụ thuộc vào sự hiện diện, vắng mặt hoặc giá trị của bất kỳ biến môi trường nào không được liệt kê ở trên.

Thư mục làm việc ban đầu sẽ là $TEST_SRCDIR/$TEST_WORKSPACE.

Mã tiến trình, mã nhóm tiến trình, mã phiên và mã tiến trình gốc hiện tại là chưa chỉ định. Quá trình này có thể là hoặc không phải là trưởng nhóm quy trình hoặc một phiên đầu tiên. Quá trình này có thể có hoặc không có thiết bị đầu cuối điều khiển. Quá trình này có thể không có hoặc có nhiều tiến trình con đang chạy hoặc chưa được xử lý. Quá trình này không được có nhiều luồng khi mã kiểm thử được kiểm soát.

Chỉ số mô tả tệp 0 (stdin) sẽ mở để đọc, nhưng nội dung được đính kèm chưa được chỉ định. Không được đọc kiểm thử từ đó. Chỉ số mô tả tệp 1 (stdout) và 2 (stderr) sẽ được phép ghi nhưng nội dung đính kèm sẽ được chưa chỉ định. Đó có thể là một thiết bị đầu cuối, một đường ống, một tệp thông thường hoặc bất kỳ tệp nào khác ký tự nào có thể viết được. Họ có thể chia sẻ một mục trong bảng tệp đang mở (có nghĩa là họ không thể tìm kiếm độc lập). Kiểm thử không được kế thừa bất kỳ các chỉ số mô tả tệp mở khác.

Màn hình umask ban đầu sẽ là 022 hoặc 027.

Không có chuông báo hoặc bộ tính giờ khoảng thời gian nào đang chờ xử lý.

Mặt nạ ban đầu của các tín hiệu bị chặn sẽ trống. Tất cả các tín hiệu sẽ được đặt thành hành động mặc định của mình.

Bạn phải đặt các giới hạn tài nguyên ban đầu, cả giới hạn mềm và cứng như sau:

Tài nguyên Hạn mức
RLIMIT_AS không giới hạn
RLIMIT_CORE chưa chỉ định
RLIMIT_CPU không giới hạn
RLIMIT_DATA không giới hạn
RLIMIT_FSIZE không giới hạn
RLIMIT_LOCKS không giới hạn
RLIMIT_MEMLOCK không giới hạn
RLIMIT_MSGQUEUE chưa chỉ định
RLIMIT_NICE chưa chỉ định
RLIMIT_NOFILE ít nhất là 1024
RLIMIT_NPROC chưa chỉ định
RLIMIT_RSS không giới hạn
RLIMIT_RTPRIO chưa chỉ định
RLIMIT_SIGPENDING chưa chỉ định
RLIMIT_STACK không giới hạn, hoặc 2044KB <= rlim <= 8192KB

Thời gian xử lý ban đầu (do times() trả về) và mức sử dụng tài nguyên (do getrusage() trả về) chưa được chỉ định.

Chính sách và mức độ ưu tiên lên lịch ban đầu chưa được chỉ định.

Vai trò của hệ thống lưu trữ

Ngoài các khía cạnh về bối cảnh của người dùng thuộc quyền kiểm soát trực tiếp của bài kiểm thử runner, hệ điều hành mà các bài kiểm thử thực thi phải đáp ứng một số để lần chạy thử nghiệm hợp lệ.

Hệ thống tệp

Thư mục gốc mà quy trình kiểm thử quan sát có thể là hoặc không phải là thư mục gốc thực.

/proc sẽ được gắn kết.

Tất cả các công cụ xây dựng sẽ có mặt tại các đường dẫn tuyệt đối trong /usr do một cài đặt cục bộ.

Các đường dẫn bắt đầu bằng /home có thể không có sẵn. Các bài kiểm thử không được truy cập vào bất kỳ các đường dẫn như vậy.

/tmp có thể ghi được, nhưng kiểm thử nên tránh sử dụng các đường dẫn này.

Phép kiểm thử không được giả định rằng mọi đường dẫn không đổi đều có sẵn cho các phép kiểm thử độc quyền và sử dụng.

Kiểm thử không được giả định rằng thời gian được bật cho bất kỳ hệ thống tệp được gắn kết nào.

Người dùng và nhóm

Phải tồn tại thư mục gốc, nobody và unittest của người dùng. Nhóm gốc, không ai và phải tồn tại.

Các bài kiểm thử phải được thực thi với tư cách một người dùng không phải người dùng gốc. Mã người dùng thực và hiệu quả phải bằng; tương tự như vậy cho id nhóm. Ngoài ra, id người dùng hiện tại, id nhóm tên người dùng và tên nhóm chưa được chỉ định. Bộ mã nhóm bổ sung là chưa chỉ định.

Id người dùng và id nhóm hiện tại phải có các tên tương ứng có thể là được truy xuất bằng getpwuid() và getgrgid(). Điều này có thể không đúng đối với mã nhóm bổ sung.

Người dùng hiện tại phải có thư mục gốc. Tệp này có thể không ghi được. Việc kiểm thử phải đừng cố gắng ghi vào đó.

Nối mạng

Tên máy chủ chưa được xác định. Ảnh này có thể chứa hoặc không chứa dấu chấm. Giải quyết tên máy chủ phải cung cấp địa chỉ IP của máy chủ lưu trữ hiện tại. Giải quyết vấn đề tên máy chủ đã bị cắt sau dấu chấm đầu tiên cũng phải hoạt động. Tên máy chủ cục bộ phải phân giải.

Tài nguyên khác

Các bài kiểm thử được cấp ít nhất một lõi CPU. Có thể có những địa chỉ khác nhưng địa chỉ này thì không được đảm bảo. Các khía cạnh khác về hiệu suất của lõi này chưa được xác định. Bạn có thể tăng mức đặt trước lên số lượng lõi CPU cao hơn bằng cách thêm thẻ &quot;cpu:n&quot; (trong đó n là số dương) đối với quy tắc kiểm thử. Nếu máy có ít tổng số lõi CPU so với yêu cầu, Bazel vẫn sẽ chạy kiểm thử. Nếu kiểm thử sử dụng phân đoạn, mỗi phân đoạn riêng lẻ sẽ dự trữ số lượng CPU lõi được chỉ định ở đây.

Kiểm thử có thể tạo ra các quy trình phụ, nhưng không xử lý các nhóm hoặc phiên.

Có giới hạn về số lượng tệp đầu vào mà chương trình kiểm thử có thể sử dụng. Giới hạn này là có thể thay đổi, nhưng hiện nằm trong phạm vi hàng chục nghìn dữ liệu đầu vào.

Ngày và giờ

Ngày và giờ hiện tại chưa được chỉ định. Múi giờ hệ thống chưa được chỉ định.

X Windows có thể chạy hoặc không. Các chương trình kiểm thử cần có máy chủ X sẽ bắt đầu Xvfb.

Kiểm thử hoạt động tương tác với hệ thống tệp

Tất cả đường dẫn tệp được chỉ định trong các biến môi trường thử nghiệm đều trỏ đến đâu đó trên hệ thống tệp cục bộ, trừ phi có quy định khác.

Chương trình kiểm thử chỉ nên tạo các tệp trong các thư mục được chỉ định bởi $TEST_TMPDIR và $TEST_UNDECLARED_OUTPUTS_DIR (nếu được đặt).

Ban đầu, các thư mục này sẽ trống.

Quá trình kiểm thử không được tìm cách xoá, chmod hoặc thay đổi các thư mục này.

Các thư mục này có thể là một đường liên kết tượng trưng.

Bạn vẫn chưa chỉ định loại hệ thống tệp của $TEST_TMPDIR/..

Các chương trình kiểm thử cũng có thể ghi tệp .part vào $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR để chú thích các tệp đầu ra chưa được khai báo.

Trong một số ít trường hợp, chương trình kiểm thử có thể buộc phải tạo tệp trong /tmp. Ví dụ: giới hạn độ dài đường dẫn cho cổng miền Unix thường yêu cầu tạo ổ cắm trong /tmp. Bazel sẽ không thể theo dõi các tệp như vậy; bản thân bài kiểm thử phải chú ý đến tính chất khép kín, để sử dụng giá trị duy nhất để tránh va chạm với các đường dẫn khác, chạy đồng thời các kiểm thử và không kiểm thử các quá trình xử lý và dọn dẹp các tệp mà công cụ này tạo ra trong /tmp.

Một số khung kiểm thử phổ biến, chẳng hạn như JUnit4 TemporaryFolder hoặc Truy cập vào TempDir, sau đó chọn cách riêng để tạo thư mục tạm thời trong /tmp. Các thử nghiệm này các khung có chức năng dọn dẹp tệp trong /tmp, nên bạn có thể dùng các tệp đó mặc dù chúng tạo tệp bên ngoài TEST_TMPDIR.

Bài kiểm thử phải truy cập vào dữ liệu đầu vào thông qua cơ chế runfiles hoặc các phần khác của môi trường thực thi dành riêng để tạo tệp đầu vào sẵn có.

Các bài kiểm thử không được truy cập vào các dữ liệu đầu ra khác của hệ thống xây dựng tại các đường dẫn được suy ra từ vị trí tệp thực thi của chính chúng.

Không xác định được liệu cây runfile có chứa các tệp thông thường, mang tính tượng trưng hay không hoặc kết hợp các đường liên kết. Cây runfiles có thể chứa các đường liên kết tượng trưng đến các thư mục. Bạn nên tránh sử dụng các đường dẫn chứa thành phần .. trong các tệp runfile cho quy trình kiểm thử cây xanh.

Không có thư mục, tệp hoặc đường liên kết tượng trưng trong cây runfile (bao gồm cả đường dẫn đường liên kết tượng trưng truyền tải) đều có thể ghi. (Theo đó, bước đầu làm việc thư mục không được ghi.) Kiểm thử không được giả định rằng bất kỳ phần nào của Các tệp runfile có thể ghi hoặc thuộc sở hữu của người dùng hiện tại (ví dụ: chmod và chgrp có thể không thành công).

Cây runfile (bao gồm cả các đường dẫn truyền tải các đường liên kết tượng trưng) không được thay đổi trong phiên chạy thử nghiệm. Không được thay đổi liên kết hệ thống tệp và thư mục mẹ theo bất kỳ cách nào ảnh hưởng đến kết quả phân giải đường dẫn trong các tệp chạy cây xanh.

Để phát hiện thoát sớm, chương trình kiểm thử có thể tạo một tệp tại đường dẫn được chỉ định bởi TEST_PREMATURE_EXIT_FILE khi bắt đầu và xoá khi thoát. Nếu Bazel thấy khi kiểm thử kết thúc, hệ thống sẽ giả định rằng chương trình kiểm thử đã thoát sớm và đánh dấu là không thành công.

Quy ước về thẻ

Một số thẻ trong quy tắc kiểm thử có ý nghĩa đặc biệt. Xem thêm Bazel Build Encyclopedia on thuộc tính tags.

Thẻ Ý nghĩa
exclusive không chạy thử nghiệm nào khác cùng một lúc
external kiểm thử có phần phụ thuộc bên ngoài; tắt tính năng lưu thử nghiệm vào bộ nhớ đệm
large Quy ước test_suite; một bộ kiểm thử lớn
manual * đừng thêm mục tiêu thử nghiệm trong các mẫu mục tiêu ký tự đại diện như :..., :* hoặc :all
medium Quy ước test_suite; bộ kiểm thử trung bình
small Quy ước test_suite; một bộ thử nghiệm nhỏ
smoke Quy ước test_suite; có nghĩa là mã nên chạy trước áp dụng thay đổi mã vào hệ thống quản lý phiên bản

Tệp chạy

Trong phần sau, giả sử có một quy tắc *_binary() được gắn nhãn //foo/bar:unittest, với phần phụ thuộc thời gian chạy trên quy tắc có nhãn //deps/server:server.

Vị trí

Thư mục runfile của một //foo/bar:unittest mục tiêu là thư mục $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. Đường dẫn này được gọi là runfiles_dir.

Phần phụ thuộc

Thư mục runfiles được khai báo là phần phụ thuộc thời gian biên dịch của *_binary() quy tắc. Bản thân thư mục runfile phụ thuộc vào nhóm BUILD các tệp ảnh hưởng đến quy tắc *_binary() hoặc bất kỳ thời gian biên dịch hay thời gian chạy nào của quy tắc đó phần phụ thuộc. Việc sửa đổi các tệp nguồn không ảnh hưởng đến cấu trúc của runfiles và do đó không kích hoạt việc tạo lại.

Nội dung

Thư mục runfiles chứa các nội dung sau:

  • Liên kết đến các phần phụ thuộc trong thời gian chạy: mỗi OutputFile và CommandRule là phần phụ thuộc thời gian chạy của quy tắc *_binary() được biểu thị bằng một đường liên kết tượng trưng trong thư mục runfile. Tên của liên kết tượng trưng là $(WORKSPACE)/package_name/rule_name. Ví dụ: đường liên kết tượng trưng cho máy chủ sẽ được đặt tên là $(WORKSPACE)/deps/server/server và đường dẫn đầy đủ sẽ là $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. Đích đến của liên kết tượng trưng là OutputFileName() của OutputFile hoặc CommandRule, được biểu thị dưới dạng đường dẫn tuyệt đối. Do đó, đích đến của đường liên kết tượng trưng có thể là $(WORKSPACE)/linux-dbg/deps/server/42/server.
  • Liên kết đến các tệp chạy con: mỗi *_binary() Z là thời gian chạy phần phụ thuộc của *_binary() C, có một đường liên kết thứ hai trong các tệp chạy thư mục C vào các tệp run của Z. Tên của liên kết tượng trưng là $(WORKSPACE)/package_name/rule_name.runfiles. Mục tiêu của liên kết tượng trưng là thư mục runfiles. Ví dụ: tất cả các chương trình con có chung một runfile thư mục.