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

Báo cáo vấn đề Xem nguồn Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Một quy cách đầy đủ về môi trường thực thi kiểm thử.

Thông tin khái quát

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

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

Người dùng cũng có thể thực thi trực tiếp các tệp nhị phân thử nghiệm. Điều này được phép nhưng không được khuyến khích, vì lệnh gọi như vậy sẽ không tuân thủ các quy định bắt buộc được mô tả bên dưới.

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

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 và hành vi dự kiến của các kiểm thử Bazel. Điều này cũng sẽ áp đặt các yêu cầu đối với trình chạy kiểm thử và hệ thống xây dựng.

Quy cách môi trường kiểm thử giúp tác giả kiểm thử tránh dựa vào hành vi không xác định, nhờ đó, cơ sở hạ tầng kiểm thử có nhiều quyền tự do hơn để thực hiện các thay đổi về việc triển khai. Quy cách này sẽ khắc phục một số lỗ hổng hiện cho phép nhiều bài kiểm thử vượt qua mặc dù không được khép kín, xác định và có thể gọi lại đúng cách.

Trang này vừa mang tính quy chuẩn vừa mang tính chính thống. Nếu thông số kỹ thuật này và hành vi đã triển khai của trình chạy kiểm thử không nhất quán, thì thông số kỹ thuật sẽ được ưu tiên.

Quy cách đề xuất

Các từ khoá "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "SẼ KHÔNG", "NÊN", "KHÔNG NÊN", "NÊN", "CÓ THỂ" và "KHÔNG BẮT BUỘC" sẽ được diễn giải như mô tả trong IETF RFC 2119.

Mục đích của các bài kiểm tra

Mục đích của các bài kiểm thử Bazel là xác nhận một số thuộc tính của các tệp nguồn được kiểm tra trong kho lưu trữ. (Trên trang này, "tệp nguồn" bao gồm dữ liệu kiểm thử, đầu ra chính xác và mọi thứ khác được lưu giữ theo chế độ kiểm soát phiên bản.) Một người dùng viết một bài kiểm thử để xác nhận một bất biến mà họ mong đợi sẽ được duy trì. Những người dùng khác sẽ thực thi kiểm thử sau để kiểm tra xem bất biến có bị phá vỡ hay không. Nếu thử nghiệm phụ thuộc vào bất kỳ biến nào khác ngoài tệp nguồn (không khép kín), thì giá trị của thử nghiệm sẽ giảm đi, vì người dùng sau này không thể chắc chắn rằng các thay đổi của họ là nguyên nhân khi thử nghiệm ngừng truyền.

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

  • các tệp nguồn mà hoạt động kiểm thử có một phần phụ thuộc đã khai báo
  • các sản phẩm của hệ thống bản dựng mà thử nghiệm có một phần phụ thuộ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 chưa thực thi quy định đối với hành vi này. Tuy nhiên, các trình chạy kiểm thử có quyền bổ sung quy trình thực thi như vậy trong tương lai.

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

Quy tắc kiểm thử tương tự như quy tắc nhị phân ở chỗ mỗi quy tắc phải tạo ra một chương trình có thể thực thi. Đối với một số ngôn ngữ, đây là một chương trình gốc kết hợp một bộ khung dành riêng cho ngôn ngữ với mã kiểm thử. Các quy tắc kiểm thử cũng phải tạo ra các đầu ra khác. 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, các tệp đầu vào phải được cung cấp cho kiểm thử tại thời gian chạy và có thể cần thông tin về loại, kích thước và thẻ của một kiểm thử.

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

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

Theo quan điểm của trình chạy kiểm thử, mỗ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 các kiểm thử; ví dụ: một IDE có thể cho phép thực thi các kiểm thử Java trong quy trình. Tuy nhiên, kết quả của việc chạy kiểm thử dưới dạng một quy trình độc lập phải được coi là có thẩm quyền. Nếu một quy trình kiểm thử chạy đến khi hoàn tất và chấm dứt bình thường với mã thoát bằng 0, thì tức là quy trình kiểm thử đã vượt qua. Mọi kết quả khác đều được coi là kiểm thử thất bại. Cụ thể, việc ghi bất kỳ chuỗi PASS hoặc FAIL nào vào stdout đều không có ý nghĩa gì đối với trình chạy kiểm thử.

Nếu một quy trình kiểm thử mất quá nhiều thời gian để thực thi, vượt quá một số giới hạn tài nguyên hoặc trình chạy kiểm thử phát hiện thấy hành vi bị cấm, thì trình chạy có thể chọn huỷ quy trình kiểm thử và coi lần chạy đó là không thành công. Trình chạy không được báo cáo rằng bài kiểm thử đã vượt qua sau khi gửi tín hiệu đến quy trình kiểm thử hoặc bất kỳ quy trình con nào của quy trình đó.

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

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

Những kiểm thử không chỉ định rõ thời gian chờ sẽ có một thời gian chờ ngầm định dựa trên size của kiểm thử như sau:

size Nhãn thời gian chờ ngầm
nhỏ ngắn
trung bình vừa
lớn long
rất lớn vĩnh cửu

Một bài kiểm thử "lớn" không có chế độ cài đặt thời gian chờ rõ ràng sẽ được phân bổ 900 giây để chạy. Bài kiểm thử "trung bình" có 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 mức sử dụng đỉnh điểm giả định của các tài nguyên khác (chẳng hạn như RAM) khi chạy kiểm thử cục bộ, như mô tả trong phần Định nghĩa chung.

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

Các kiểm thử có thể trả về nhanh chóng tuỳ ý bất kể thời gian chờ. Thử nghiệm không bị phạt vì thời gian chờ quá dài, mặc dù có thể đưa ra cảnh báo: bạn thường nên đặt thời gian chờ càng ngắn càng tốt mà không gặp phải bất kỳ sự không nhất quán nào.

Bạn có thể ghi đè thời gian chờ kiểm thử bằng cờ --test_timeout bazel khi chạy theo cách thủ công trong các điều kiện được biết là chậm. Các giá trị --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 đặt thời gian chờ kiểm thử ở mức tối thiểu như sau:

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

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

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

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

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

Bạn có thể song song hoá các kiểm thử thông qua tính năng phân đoạn kiểm thử. Hãy xem --test_sharding_strategy và shard_count để bật tính năng phân đoạn thử nghiệm. Khi tính năng phân đoạn được bật, 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ố lượng phân đoạn và TEST_SHARD_INDEX là chỉ mục phân đoạn, bắt đầu từ 0. Trình chạy sử dụng thông tin này để chọn những kiểm thử cần chạy (ví dụ: sử dụng chiến lược luân phiê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ợ phân đoạn, trình chạy phải tạo hoặc cập nhật ngày sửa đổi gần đây nhất của tệp do TEST_SHARD_STATUS_FILE chỉ định. Nếu không, nếu --incompatible_check_sharding_support được bật, Bazel sẽ không vượt qua được kiểm thử nếu kiểm thử đó được phân mảnh.

Điều kiện ban đầu

Khi thực thi một bài kiểm thử, trình chạy kiểm thử phải thiết lập một số điều kiện ban đầu nhất định.

Trình chạy kiểm thử phải gọi 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 bên dưới thư mục hiện tại của kiểm thử (nằm trong cây runfiles, xem bên dưới). Trình chạy kiểm thử không được truyền bất kỳ đối số nào khác cho một kiểm thử, trừ phi người dùng yêu cầu một cách rõ ràng.

Khối môi trường ban đầu sẽ được tạo thành như sau:

Biến Giá trị Trạng thái
HOME giá trị của $TEST_TMPDIR được đề nghị
LANG unset bắt buộc
LANGUAGE unset bắt buộc
LC_ALL unset bắt buộc
LC_COLLATE unset bắt buộc
LC_CTYPE unset bắt buộc
LC_MESSAGES unset bắt buộc
LC_MONETARY unset bắt buộc
LC_NUMERIC unset bắt buộc
LC_TIME unset bắt buộc
LD_LIBRARY_PATH danh sách các thư mục chứa thư viện dùng chung, được phân tách bằng dấu hai chấm 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 một thư mục có thể ghi (Bạn chỉ nên dùng tệp này để báo cáo các lỗi bắt nguồn từ cơ sở hạ tầng kiểm thử, chứ không phải là cơ chế chung để báo cáo các lỗi không ổn định của các kiểm thử. Trong bối cảnh này, cơ sở hạ tầng kiểm thử được xác định 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 lỗi kiểm thử do hoạt động không đúng cách. Dòng đầu tiên là tên của thành phần cơ sở hạ tầng kiểm thử gây ra lỗi, dòng thứ hai là nội dung mô tả lỗi mà con người có thể đọc được. 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 (được dùng để ghi nhật ký Logsplitter protobuffer) tùy chọn
TEST_PREMATURE_EXIT_FILE đường dẫn tuyệt đối đến một tệp riêng tư trong một thư mục có thể ghi (được dùng để bắt các lệnh gọi đến exit()) tùy chọn
TEST_RANDOM_SEED Nếu bạn sử dụng tuỳ chọn --runs_per_test, TEST_RANDOM_SEED sẽ được đặt thành run number (bắt đầu từ 1) cho từng lần chạy kiểm thử riêng lẻ. tùy chọn
TEST_RUN_NUMBER Nếu bạn sử dụng tuỳ chọn --runs_per_test, TEST_RUN_NUMBER sẽ được đặt thành run number (bắt đầu từ 1) cho từng 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 kiểm thử tùy chọn
TEST_SIZE Bài kiểm tra size tùy chọn
TEST_TIMEOUT Thời gian kiểm tra timeout tính bằng giây tùy chọn
TEST_SHARD_INDEX chỉ mục phân đoạn, nếu sharding được dùng tùy chọn
TEST_SHARD_STATUS_FILE đường dẫn đến tệp cần chạm vào để cho biết có hỗ trợ sharding hay không tùy chọn
TEST_SRCDIR đường dẫn tuyệt đối đến cơ sở của cây runfiles bắt buộc
TEST_TOTAL_SHARDS tổng shard count, nếu bạn sử dụng sharding tùy chọn
TEST_TMPDIR đường dẫn tuyệt đối đến một thư mục riêng tư 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 một thư mục riêng tư có thể ghi (được dùng để ghi các đầu ra kiểm thử chưa khai báo). Mọi tệp đượ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 một thư mục riêng tư có thể ghi (được dùng để ghi chú thích đầu ra kiểm thử chưa khai báo .part và tệp .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 mục tiêu kiểm thử) 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à các thao tác kiểm thử sẽ ghi tệp đầu ra XML kết quả kiểm thử. Nếu không, Bazel sẽ tạo một tệp đầu ra XML mặc định bao bọc nhật ký kiểm thử như một phần của thao tác kiểm thử. Lược đồ XML dựa trên lược đồ 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 điều khiển bởi bazel test bắt buộc

Môi trường có thể chứa các mục bổ sung. Các kiểm thử không được 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ã quy trình hiện tại, mã nhóm quy trình, mã phiên và mã quy trình mẹ không được chỉ định. Quy trình này có thể là hoặc không phải là một quy trình trưởng nhóm hoặc một trưởng phiên. Quy trình này có thể có hoặc không có một thiết bị đầu cuối kiểm soát. Quy trình này có thể có 0 hoặc nhiều quy trình con đang chạy hoặc chưa được thu thập. Quy trình này không được có nhiều luồng khi mã kiểm thử giành được quyền kiểm soát.

Bạn phải mở bộ mô tả tệp 0 (stdin) để đọc, nhưng không xác định được bộ mô tả này được đính kèm vào nội dung nào. Các kiểm thử không được đọc từ đó. Bộ mô tả tệp 1 (stdout) và 2 (stderr) sẽ được mở để ghi, nhưng không xác định được chúng được đính kèm vào bộ mô tả nào. Đó 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ỳ thứ gì khác mà các ký tự có thể được ghi vào. Chúng có thể chia sẻ một mục trong bảng tệp đang mở (nghĩa là chúng không thể tìm kiếm độc lập). Các kiểm thử không được kế thừa bất kỳ bộ mô tả tệp mở nào khác.

Umask ban đầu sẽ là 022 hoặc 027.

Không có chuông báo hoặc đồng hồ hẹn 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.

Bạn nên đặt hạn mức tài nguyên ban đầu (cả hạn mức mềm và hạn mức 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 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ề) không được chỉ định.

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

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

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

Hệ thống tệp

Thư mục gốc mà một bài kiểm thử quan sát được có thể là hoặc không phải là thư mục gốc thực.

/proc phải được gắn.

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

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

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

Các kiểm thử không được giả định rằng có sẵn đường dẫn hằng số để sử dụng riêng.

Các kiểm thử không được giả định rằng atime được bật cho bất kỳ hệ thống tệp nào đã gắn.

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

Người dùng root, nobody và unittest phải tồn tại. Các nhóm root, nobody và eng phải tồn tại.

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

Mã nhận dạng người dùng và mã nhận dạng nhóm hiện tại phải có tên tương ứng có thể 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 chính. Có thể bạn không ghi được vào ổ đĩa này. Các kiểm thử không được cố gắng ghi vào đó.

Nối mạng

Tên máy chủ chưa được chỉ định. Có thể có hoặc không có dấu chấm. Việc phân giải tên máy chủ phải cung cấp địa chỉ IP của máy chủ hiện tại. Việc phân giải 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 kiểm thử được cấp ít nhất một lõi CPU. Các lựa chọn khác có thể có nhưng 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 không được chỉ định. Bạn có thể tăng số lượng lõi CPU được đặt trước bằng cách thêm thẻ "cpu:n" (trong đó n là một số dương) vào một quy tắc kiểm thử. Nếu một máy có tổng số lõi CPU ít hơn số lượng được yêu cầu, Bazel vẫn sẽ chạy kiểm thử. Nếu một kiểm thử sử dụng phân đoạn, thì mỗi phân đoạn riêng lẻ sẽ dự trữ số lượng lõi CPU được chỉ định ở đây.

Các kiểm thử có thể tạo ra các quy trình con, nhưng không tạo ra các nhóm quy trình hoặc phiên.

Có giới hạn về số lượng tệp đầu vào mà một bài kiểm thử có thể sử dụng. Giới hạn này có thể thay đổi, nhưng hiện tại nằm trong khoảng hàng chục nghìn đầ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ể có hoặc không có sẵn. Các kiểm thử cần có máy chủ X phải 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 kiểm thử đều trỏ đến một vị trí nào đó trên hệ thống tệp cục bộ, trừ phi được chỉ định khác.

Các kiểm thử chỉ được tạo tệp trong các thư mục do $TEST_TMPDIR và $TEST_UNDECLARED_OUTPUTS_DIR chỉ định (nếu được đặt).

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

Các bài 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à đường liên kết tượng trưng.

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

Các 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 khai báo.

Trong một số ít trường hợp, một thử nghiệm có thể buộc phải tạo các tệp trong /tmp. Ví dụ: giới hạn độ dài đường dẫn cho các socket miền Unix thường yêu cầu tạo socket trong /tmp. Bazel sẽ không thể theo dõi những tệp như vậy; bản thân chương trình kiểm thử phải đảm bảo tính khép kín, sử dụng các đường dẫn riêng biệt để tránh xung đột với các chương trình kiểm thử và quy trình không phải kiểm thử khác đang chạy đồng thời, đồng thời dọn dẹp các tệp mà chương trình kiểm thử tạo trong /tmp.

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

Các 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 được thiết kế riêng để cung cấp các tệp đầu vào.

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

Không xác định liệu cây runfiles có chứa các tệp thông thường, đường liên kết tượng trưng hay hỗn hợp hay không. Cây runfiles có thể chứa các đường liên kết tượng trưng đến các thư mục. Các bài kiểm thử nên tránh sử dụng những đường dẫn chứa các thành phần .. trong cây runfiles.

Không có thư mục, tệp hoặc đường liên kết tượng trưng nào trong cây runfiles (bao gồm cả các đường dẫn đi qua đường liên kết tượng trưng) có thể ghi. (Do đó, bạn không được phép ghi vào thư mục làm việc ban đầu.) Các kiểm thử không được giả định rằng bất kỳ phần nào của runfiles đều 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 runfiles (bao gồm cả các đường dẫn đi qua symlink) không được thay đổi trong quá trình thực thi kiểm thử. Thư mục mẹ và các điểm gắn kết hệ thống tệp không được thay đổi theo bất kỳ cách nào ảnh hưởng đến kết quả của việc phân giải một đường dẫn trong cây runfiles.

Để phát hiện trường hợp thoát sớm, một quy trình kiểm thử có thể tạo một tệp tại đường dẫn do TEST_PREMATURE_EXIT_FILE chỉ định khi bắt đầu và xoá tệp đó khi thoát. Nếu Bazel thấy tệp này khi quá trình kiểm thử kết thúc, thì Bazel sẽ giả định rằng quá trình kiểm thử đã kết thúc 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 Bách khoa toàn thư về bản dựng Bazel đối với thuộc tính tags.

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

Runfiles

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

Thông tin vị trí

Thư mục runfiles cho mục tiêu //foo/bar:unittest 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à một phần phụ thuộc trong thời gian biên dịch của quy tắc *_binary(). Bản thân thư mục runfiles phụ thuộc vào tập hợp các tệp BUILD ảnh hưởng đến quy tắc *_binary() hoặc bất kỳ phần phụ thuộc nào trong thời gian biên dịch hoặc thời gian chạy của quy tắc đó. Việc sửa đổi các tệp nguồn không ảnh hưởng đến cấu trúc của thư mục runfiles, do đó không kích hoạt bất kỳ quá trình tạo lại nào.

Nội dung

Thư mục runfiles chứa những nội dung sau:

  • Symlink đến các phần phụ thuộc trong thời gian chạy: mỗi OutputFile và CommandRule là một phần phụ thuộc trong thời gian chạy của quy tắc *_binary() được biểu thị bằng một symlink trong thư mục runfiles. Tên của đường liên kết tượng trưng là $(WORKSPACE)/package_name/rule_name. Ví dụ: symlink cho máy chủ sẽ có 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 symlink 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 symlink có thể là $(WORKSPACE)/linux-dbg/deps/server/42/server.
  • Symlink đến các tệp phụ: đối với mọi *_binary() Z là một phần phụ thuộc thời gian chạy của *_binary() C, sẽ có một đường liên kết thứ hai trong thư mục runfiles của C đến runfiles của Z. Tên của đường liên kết tượng trưng là $(WORKSPACE)/package_name/rule_name.runfiles. Mục tiêu của symlink là thư mục runfiles. Ví dụ: tất cả các chương trình con đều dùng chung một thư mục runfiles.