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

Báo cáo vấn đề Xem nguồn Hằng đêm · 7,4 của Google. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Thông số kỹ thuậ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 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, vì lệnh gọi như vậy sẽ không tuân thủ các yêu cầu được mô tả bên dưới.

Các bài kiểm thử phải khép kín: tức là chỉ được truy cập vào những tài nguyên mà chúng có phần phụ thuộ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à thiết lập chính thức môi trường thời gian chạy và hành vi dự kiến của các 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 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ờ đó cho phép cơ sở hạ tầng kiểm thử tự do hơn trong việc thực hiện các thay đổi. Quy cách này thắt chặt 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 kín, xác định và có thể truy cập lại đúng cách.

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

Thông số kỹ thuật đề 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 kiểm thử, đầu ra chuẩn và mọi nội dung khác được kiểm soát 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 đã bị hỏng hay chưa. Nếu quy trình 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), thì giá trị của quy trình kiểm thử sẽ giảm xuống, 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 quy trình kiểm thử ngừng vượt qua.

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

  • tệp nguồn mà kiểm thử có phần phụ thuộ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
  • tài nguyên có hành vi được trình chạy kiểm thử đảm bảo luôn không đổi

Hiện tại, chúng tôi chưa thực thi hành vi như vậy. Tuy nhiên, trình chạy kiểm thử giữ quyền 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

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 mô phỏng kết hợp một bộ điều khiển dành riêng cho ngôn ngữ với mã kiểm thử. 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 tệp kê khai runfiles (tệp chạy), tệp đầu vào cần được cung cấp cho 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à thẻ của kiểm thử.

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. (Đây có thể được dùng làm phương pháp tối ưu hoá để làm cho mỗi tệp nhị phân kiểm thử nhỏ hơn bằng cách chia sẻ các tệp trên 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 được tạo sẽ tải các tệp này thông qua hình ảnh tệp chạy do trình chạy kiểm thử cung cấp, thay vì tham chiếu được mã hoá cứng đến các vị trí tuyệt đối trong cây nguồn hoặc đầ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ả 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à 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ử. Ngang bằng 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à đã 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 kiểm thử đó.

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
vừa 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ầm ẩn
nhỏ ngắn
trung bình vừa
lớn long
rất lớn vĩnh cửu

Một 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. Một kiểm thử "trung bình" có thời gian chờ "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 cao nhất giả định của các tài nguyên khác (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, bạn có thể khai báo một kiểm thử "rất lớn" có thời gian chờ "ngắn". Có thể nó sẽ thực hiện một số việc thực sự kinh khủng rất nhanh chóng.

Các chương trình kiểm thử có thể trả về nhanh tuỳ ý bất kể 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. 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 hai 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
vừa 30
long 300
vĩnh cửu 900

Ví dụ: nếu một kiểm thử "trung bình" hoàn tất trong 5,5 giây, hãy cân nhắc đặt timeout = "short" hoặc size = "small". Việc sử dụng tuỳ chọn dòng lệnh bazel --test_verbose_timeout_warnings 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 bạn không chỉ định, kích thước của kiểm thử sẽ mặc định là "vừa".

Nếu quy trình chính của một kiểm thử thoát, nhưng một số quy trình con vẫn đang chạy, thì trình chạy kiểm thử sẽ xem xét quá trình chạy đã hoàn tất và tính là thành công hoặc không thành công dựa trên mã thoát được quan sát từ quy 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ố lượng phân mảnh và TEST_SHARD_INDEX là chỉ mục phân mảnh, bắt đầu từ 0. Trình chạy sử dụng thông tin này để chọn kiểm thử nào sẽ 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 trình chạy hỗ trợ tính năng phân đoạn, thì trình chạy nà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ẽ được tạo 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 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 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 thư mục có thể ghi (Tệp này chỉ nên được dùng để báo cáo 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 lỗi không ổn định của kiểm thử. Trong ngữ 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 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ý protobuffer Logsplitter) 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 để phát hiện 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, thì TEST_RANDOM_SEED sẽ được đặt thành run number (bắt đầu từ 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 Kiểm thử size tùy chọn
TEST_TIMEOUT Kiểm thử 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 sử dụng tùy chọn
TEST_SHARD_STATUS_FILE đường dẫn đến tệp cần nhấn để cho biết khả năng 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 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 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ử). 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 (dùng để ghi các tệp chú thích đầu ra kiểm thử .part và .pb chưa khai báo). 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 bao gồm nhật ký kiểm thử trong hành động 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 bazel test thực thi bắt buộc

Môi trường có thể chứa các mục nhập khác. Các chương trình kiểm thử không được phụ thuộc vào việc có, không có hoặc giá trị của bất kỳ biến môi trường nào không có trong danh sách 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. 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ẽ được mở để đọc, nhưng nội dung đính kèm vào chỉ số này không được chỉ định. Các chương trình kiểm thử không được đọc từ tệp này. Chỉ số mô tả tệp 1 (stdout) và 2 (stderr) sẽ được mở để ghi, nhưng nội dung đính kèm vào các chỉ số này là không xác định. Đó có thể là một thiết bị đầu cuối, một ống dẫn, một tệp thông thường hoặc bất kỳ thứ gì khác mà bạn có thể ghi ký tự. 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). Các chương trình kiểm thử không được kế thừa bất kỳ mô tả tệp mở nào khác.

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

Không có chuông báo hoặc đồng hồ hẹn giờ theo 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 phải 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 các giới hạn tài nguyên ban đầu, cả giới hạn mềm và giới hạn 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ề) chưa được chỉ định.

Chính sách và mức độ ưu tiên lập 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 của ngữ cảnh người dùng nằm trong quyền kiểm soát trực tiếp của trình chạy kiểm thử, hệ điều hành nơi các 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ử 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.

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 mà một quá trình cài đặt cục bộ sử dụng.

Các đường dẫn bắt đầu bằng /home có thể không có sẵn. Các chương trình kiểm thử không được truy cập vào bất kỳ đường dẫn nào 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

Người dùng gốc, không ai và kiểm thử đơn vị phải tồn tại. Các nhóm root, nobody và eng 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ã nhận dạng người dùng thực và hiệu quả phải bằng nhau; tương tự như mã nhận dạng nhóm. Ngoài ra, mã nhận dạng người dùng, mã nhận dạng nhóm, tên người dùng và tên nhóm hiện tại không được chỉ định. Bộ mã nhóm bổ sung là chưa chỉ định.

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 mà bạn 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 gốc. Tệp này có thể không ghi được. Các chương trình kiểm thử không được cố gắng ghi vào đó.

Nối mạng

Tên máy chủ chưa được xác định. Tên 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. 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ủ localhost phải phân giải được.

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 điểm khác, nhưng đây không phải là đượ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 số lượng lõi CPU được đặt trước lên bằng cách thêm thẻ "cpu:n" (trong đó n là một số dương) vào 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 một chương trình kiểm thử sử dụng tính năng phân đoạn, thì mỗi phân đoạn riêng lẻ sẽ dành riêng số lượng lõi CPU được chỉ định tại đây.

Các chương trình kiểm thử có thể tạo quy trình con nhưng không thể xử lý 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 khoảng 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.

Có thể có hoặc không có Cửa sổ X. 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 biến môi trường kiểm thử đều trỏ đến một vị trí trên hệ thống tệp cục bộ, trừ phi được chỉ đị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 khai báo.

Trong một số ít trường hợp, quy 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ắm 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; chính quá trình kiểm thử phải cẩn thận để đảm bảo tính kín đáo, sử dụng các đường dẫn duy nhất để tránh xung đột với các quy trình kiểm thử và không kiểm thử khác đang chạy đồng thời, cũng như để dọn dẹp các tệp mà quá trình kiểm thử tạo ra trong /tmp.

Một số khung kiểm thử phổ biến, chẳng hạn như JUnit4 TemporaryFolder hoặc Go TempDir, có 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 chương trình kiểm thử không được truy cập vào các đầ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í của tệp thực thi của chính chúng.

Không xác định liệu cây tệp chạy có chứa tệp thông thường, đường liên kết tượng trưng hay cả hai. Cây tệp chạy có thể chứa các đường liên kết tượng trưng đến 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ây tệp chạy.

Không được ghi vào thư mục, tệp hoặc đường liên kết tượng trưng trong cây tệp chạy (bao gồm cả các đường dẫn đi qua đường liên kết tượng trưng). (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. Thư mục mẹ và các điểm gắn 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ả phân giải đường dẫn trong cây tệp chạy.

Để 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 tệp khi kiểm thử kết thúc, thì Bazel sẽ giả định rằng kiểm thử đã thoát sớm và đánh dấu kiểm thử đó 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 the tags thuộc tính.

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; bộ kiểm thử lớn
manual * không đưa mục tiêu kiểm thử vào mẫu mục tiêu đại diện như :..., :* hoặc :all
medium quy ước test_suite; bộ kiểm thử trung bình
small quy ước test_suite; bộ kiểm thử nhỏ
smoke Quy ước test_suite; nghĩa là bạn nên chạy trước khi thực hiện các thay đổi về mã vào hệ thống quản lý 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, 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 tại thời điểm biên dịch của quy tắc *_binary(). 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 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 quá trình tạo lại.

Nội dung

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

  • Đường liên kết tượng trưng đến các phần phụ thuộc thời gian chạy: mỗi OutputFile và CommandRule là một 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 runfiles. 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ê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.
  • Đường liên kết tượng trưng đến tệp chạy phụ: đối với mỗi *_binary() Z là 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 tệp chạy của C đến tệp chạy 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 đường 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 đều dùng chung một thư mục runfiles.