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

Báo cáo sự cố Xem nguồn

Thông số đầ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ể dùng để xác định các chương trình kiểm thử tự động bằng nhiều ngôn ngữ.

Bạn có thể chạy kiểm thử bằng cách sử dụ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ì một lệnh gọi như vậy sẽ không tuân thủ các uỷ nhiệm được mô tả bên dưới.

Hoạt động kiểm thử nên có tính khép kín: tức là chỉ nên truy cập vào các tài nguyên đã khai báo phần phụ thuộc. Nếu các thử nghiệm không mang tính khép kín đúng cách, thì sẽ không cho kết quả có thể mô phỏng trước đây. Đây có thể là một vấn đề quan trọng trong việc tìm ra thủ phạm (xác định thay đổi nào đã phá vỡ kiểm thử), khả năng kiểm tra kỹ thuật phát hành và cách ly tài nguyên của các bài kiểm thử (khung kiểm thử tự động không được DDOS máy chủ vì một số quá trình kiểm thử tình cờ trao đổi 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 các kiểm thử Bazel. Ngoài ra, quy tắc này cũng áp dụng các yêu cầu đối với trình chạy kiểm thử và hệ thống xây dựng.

Thông số kỹ thuật về 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 được chỉ định, do đó cho phép cơ sở hạ tầng kiểm thử tự do thực hiện các thay đổi triển khai hơn. Thông số kỹ thuật thu hẹp một số lỗ hổng hiện cho phép nhiều kiểm thử vượt qua mặc dù không được bảo mật, xác định và lặp lại đúng cách.

Mục đích của trang này là vừa mang tính quy chuẩn vừa có căn cứ. Nếu quy cách này và hành vi được triển khai của trình chạy kiểm thử không đồng ý với nhau, thì quy cách đó sẽ được ưu tiên.

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

Các từ khoá "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "KHÔNG NÊN", "KHÔNG NÊN", "NÊN", "KHÔNG NÊN", "ĐƯỢC ĐỀ XUẤT", "CÓ THỂ" và "KHÔNG BẮT BUỘC" sẽ được hiểu như mô tả trong IETF RFC 2119.

Mục đích 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 đã đăng ký vào kho lưu trữ. (Trên trang này, "tệp nguồn" bao gồm dữ liệu thử nghiệm, đầu ra bằng vàng và mọi dữ liệu khác được lưu giữ trong chế độ quản lý phiên bản.) Một người dùng viết bài kiểm thử để xác nhận một bất biến mà họ muốn duy trì. Những người dùng khác sẽ thực thi kiểm thử sau để kiểm tra xem tính bất biến có bị hỏng hay không. Nếu chương 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 bảo mật), thì giá trị của hoạt động kiểm thử sẽ giảm đi vì những người dùng sau này không thể chắc chắn rằng những thay đổi của họ là có lỗi khi kiểm thử ngừng đạt.

Do đó, kết quả của kiểm thử chỉ nên 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 đã khai báo
  • các tài nguyên có hành vi được trình chạy kiểm thử đảm bảo không đổi

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

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

Các quy tắc kiểm thử cũng tương tự như các quy tắc nhị phân, trong đó 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à chương trình mã giả lập kết hợp một phần khai thác 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 gồm runfiles, tệp đầu vào được cung cấp cho quá trình 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 bài kiểm thử.

Hệ thống xây dựng có thể sử dụng các tệp runfile để phân phối mã cũng như dữ liệu. (Tính năng này có thể được dùng để tối ưu hoá nhằm thu nhỏ từng tệp nhị phân kiểm thử bằng cách chia sẻ tệp giữa các quá trình 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ì mã tham chiếu cứng các tệp tham chiếu đế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ử

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

Nếu quá 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 hành vi bị cấm, thì kiểm thử đó có thể chọn tắt tính năng kiểm thử và coi lần chạy đó là một lỗi. Trình chạy không được báo cáo kiểm thử là đạt sau khi gửi tín hiệu đến quy trình kiểm thử hoặc bất kỳ tín hiệu 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 các 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 đến khi hoàn tất. Giới hạn thời gian kiểm thử sẽ 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
trung bình 300
long 900
vĩnh viễn 3600

Đối với các phép kiểm thử không chỉ định rõ thời gian chờ, có một hàm ngụ ý dựa trên size của kiểm thử như sau:

size Nhãn hết thời gian chờ ngụ ý
nhỏ ngắn
trung bình trung bình
lớn long
to lớn vĩnh viễn

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. Thử nghiệm "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 xác định thêm mức sử dụng cao nhất được 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 Các định nghĩa phổ biến.

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

Quá trình kiểm thử có thể trả về nhanh tuỳ ý bất kể thời gian chờ. Mặc dù có thể đưa ra cảnh báo nhưng kiểm thử không bị phạt do hết thời gian chờ quá mức, nhưng bạn nên đặt thời gian chờ ở mức cố định nhất có thể để không gây ra bất kỳ sự gián đoạn nào.

Bạn có thể ghi đè thời gian chờ kiểm thử bằng cờ bazel --test_timeout khi chạy thủ công trong các điều kiện được xác định 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, còn có một giới hạn dưới được đề xuất 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 viễn 900

Ví dụ: Nếu một bài kiểm thử "trung bình" hoàn thành trong 5, 5 giây, hãy cân nhắc thiết lập 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 chương trình 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 không chỉ định, kích thước của một kiểm thử sẽ 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 nó vẫn đang chạy, thì trình chạy kiểm thử nên coi lần chạy đó là đã hoàn tất và tính đó là một lần chạy thành công hoặc không thành công 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 sai lệch. Kiểm thử không nên làm rò rỉ quy trình theo cách này.

Kiểm thử tính năng phân đoạn

Bạn có thể tải song song các bài 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 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 đoạn và TEST_SHARD_INDEX là 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 bài kiểm thử cần 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ợ tính năng 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 đó phải tạo hoặc cập nhật ngày được sửa đổi gần đây nhất của tệp do TEST_SHARD_STATUS_FILE chỉ định. 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 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.

Trình chạy kiểm thử phải gọi từng lượt 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 tương đối và nằm bên dưới thư mục hiện tại của hoạt động 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 đến hoạt động 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ó cấu trúc như sau:

Biến Giá trị Trạng thái
HOME giá trị của $TEST_TMPDIR được đề xuất
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 được phân tách bằng dấu hai chấm có chứa thư viện dùng chung không bắt buộc
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 đề xuất
PWD $TEST_SRCDIR/workspace-name được đề xuất
SHLVL 2 được đề xuất
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 (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à một cơ chế chung để báo cáo các lượt kiểm thử không ổn định. 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 lỗi kiểm thử do hoạt động sai 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.) không bắt buộc
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 của bộ chia nhật ký) không bắt buộc
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 để thu thập lệnh gọi đến exit()) không bắt buộc
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 bằng 1) cho mỗi lần chạy kiểm thử. không bắt buộc
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 bằng 1) cho mỗi lần chạy kiểm thử. không bắt buộc
TEST_TARGET Tên của mục tiêu đang được thử nghiệm không bắt buộc
TEST_SIZE Thử nghiệm size không bắt buộc
TEST_TIMEOUT Thử nghiệm timeout tính bằng giây không bắt buộc
TEST_SHARD_INDEX chỉ mục phân đoạn, nếu sử dụng sharding không bắt buộc
TEST_SHARD_STATUS_FILE đường dẫn đến tệp để chạm vào để cho biết sự hỗ trợ dành cho sharding không bắt buộc
TEST_SRCDIR đường dẫn tuyệt đối đến gốc cây runfiles bắt buộc
TEST_TOTAL_SHARDS tổng shard count, nếu sử dụng sharding không bắt buộc
TEST_TMPDIR đường dẫn tuyệt đối đến thư mục ghi riêng tư bắt buộc
TEST_WORKSPACE tên không gian làm việc của kho lưu trữ cục bộ không bắt buộc
TEST_UNDECLARED_OUTPUTS_DIR đường dẫn tuyệt đối đến thư mục có thể ghi riêng tư (dùng để ghi các kết quả kiểm thử không được 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. không bắt buộc
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR đường dẫn tuyệt đối đến thư mục có thể ghi riêng tư (dùng để ghi các tệp chú thích đầu ra kiểm thử .part và .pb chưa được khai báo). không bắt buộc
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 để viết cảnh báo về mục tiêu kiểm thử) không bắt buộc
TESTBRIDGE_TEST_ONLY giá trị của --test_filter, nếu được chỉ định không bắt buộc
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ử sẽ ghi tệp đầu ra XML của 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 kiểm thử. Giản đồ XML dựa trên giản đồ kết quả kiểm thử JUnit. không bắt buộc
BAZEL_TEST Dấu hiệu cho thấy tệp thực thi kiểm thử đang do bazel test điều khiển bắt buộc

Môi trường có thể chứa các mục nhập bổ sung. Hoạt động kiểm thử không nên phụ thuộc vào mức độ 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.

Không chỉ định mã quy trình hiện tại, mã nhóm quy trình, mã phiên và mã quy trình gốc. Quá trình này có thể là hoặc không phải là trưởng nhóm quy trình hoặc người dẫn dắt phiên. Quá trình có thể có hoặc không có thiết bị đầu cuối kiểm soát. Quy trình này có thể không có hoặc có nhiều quy trình con đang chạy hoặc chưa được truy xuất. Quy trình này không được có nhiều luồng khi mã kiểm thử giành quyền kiểm soát.

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

Giá trị umask ban đầu sẽ là 022 hoặc 027.

Không có chuông báo hoặc đồng hồ hẹn giờ nào ở trạng thái đ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ả tín hiệu sẽ được đặt thành hành động mặc định.

Bạn nên đặt giới hạn tài nguyên ban đầu, cả 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 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

Không xác định thời gian xử lý ban đầu (do times() trả về) và việc sử dụng tài nguyên (do getrusage() trả về).

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

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 trình chạy kiểm thử, hệ điều hành nơi thực thi các hoạt động kiểm thử phải đáp ứng một số thuộc tính nhất định để lượt 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 có thể là hoặc không phải là thư mục gốc thực sự.

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

Mọi công cụ bản dựng đều xuất hiện tại đường dẫn tuyệt đối trong /usr được quá trình cài đặt cục bộ sử dụng.

Có thể không có đường dẫn bắt đầu bằng /home. Hoạt động kiểm thử không nên 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.

Kiểm thử không được giả định rằng có sẵn đường dẫn cố định để sử dụng riê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 nào được gắn kết.

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

Các 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 gốc, không ai và kỹ thuật phải tồn tại.

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

Mã nhận dạng người dùng và mã nhóm hiện tại phải có tên tương ứng, có thể truy xuất được bằng getpwuid() và getgrgid(). Điều này có thể không đúng đối với các 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. Quy trình kiểm thử không được cố gắng ghi vào đó.

Mạng

Chưa xác định tên máy chủ. Nó có thể chứa hoặc không chứa 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 xử lý việc cắt tên máy chủ sau dấu chấm đầu tiên cũng phải có tác dụng. Tên máy chủ localhost phải phân giải.

Tài nguyên khác

Các chương trình kiểm thử được cấp ít nhất một lõi CPU. Một số nguồn khác có thể có sẵn nhưng điều này không được đảm bảo. Các khía cạnh hiệu suất khác của lõi này không được nêu rõ. Bạn có thể tăng số lượng lõi CPU đặt trước lên số lõi CPU cao hơn bằng cách thêm thẻ "cpu:n" (trong đó n là số dương) vào quy tắc kiểm thử. Nếu một máy có tổng số lõi CPU thấp hơn yêu cầu, Bazel vẫn sẽ chạy kiểm thử. Nếu một 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õi CPU được chỉ định ở đây.

Kiểm thử có thể tạo các quy trình phụ, 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à 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 là 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 xác định. Chưa chỉ định múi giờ hệ thống.

X Windows có thể khả dụng hoặc không khả dụng. Các quá trình kiểm thử cần máy chủ X nên bắt đầu Xvfb.

Kiểm thử 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í nào đó trên hệ thống tệp cục bộ, trừ khi có quy định khác.

Kiểm thử chỉ nên 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.

Quy trình kiểm thử không được tìm cách xoá, chỉnh sửa 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 đượ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ắ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; bản thân quy trình kiểm thử phải đảm bảo tính khép kín, sử dụng các đường dẫn duy nhất để tránh xung đột với các quy trình khác chạy đồng thời các quy trình kiểm thử và không kiểm thử, cũng như dọn dẹp các tệp mà công cụ này 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ó các 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 xoá các tệp trong /tmp. Vì vậy, bạn có thể sử dụng các khung này mặc dù các khung này tạo tệp bên ngoài TEST_TMPDIR.

Hoạt động 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 nhằm cung cấp tệp đầu vào.

Kiểm thử không được truy cập vào các kết quả 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 nó.

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

Để phát hiện tình trạng thoát sớm, 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 kiểm thử kết thúc, Bazel sẽ giả định rằng 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 Bách khoa toàn thư về bản dựng trên thuộc tính tags.

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

Tệp Run

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

Vị trí

Thư mục runfiles của //foo/bar:unittest đích 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 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 thời gian biên dịch hay thời gian chạy nào của quy tắ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, và do đó không kích hoạt bất kỳ hoạt động tạo lại nào.

Nội dung

Thư mục runfiles chứa các thông tin sau:

  • Liên kết đến các phần phụ thuộc 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 runfiles. Tên của đường 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 đường 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: đố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 runfiles của C đến các runfile 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 đườ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 có chung một thư mục runfile chung.