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ữ BUILD của Bazel bao gồm các quy tắc có thể dùng để xác định chương trình kiểm thử tự động bằng nhiều ngôn ngữ.
Các chương trình 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: nghĩa 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 các chương trình kiểm thử không kín đáo đú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à vấn đề đáng kể đối với việc tìm nguyên nhân gây ra lỗi (xác định thay đổi nào đã làm hỏng một kiểm thử), khả năng kiểm tra kỹ thuật phát hành và khả năng tách biệt tài nguyên của các kiểm thử (khung kiểm thử tự động không được DDOS máy chủ vì một số kiểm thử có thể giao tiếp với máy chủ đó).
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. Đ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.
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. Thông số kỹ thuật 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 phạm 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ừ khoá "PHẢI", "KHÔNG ĐƯỢC", "BẮT BUỘC", "SẼ", "KHÔNG SẼ", "NÊN", "KHÔNG NÊN", "NÊN DÙNG", "CÓ THỂ" và "KHÔNG BẮT BUỘC" phải được diễn giải như mô tả trong IETF RFC 2119.
Mục đích của kiểm thử
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 vào 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 chương trình kiểm thử để xác nhận một hằng số mà họ muốn duy trì. Người dùng khác sẽ thực thi kiểm thử sau để kiểm tra xem hằng số không đổi có bị vi phạm 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), thì giá trị của kiểm thử sẽ giảm, 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à lỗi khi 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
- các sản phẩm của hệ thống xây dựng mà kiểm thử có phần phụ thuộ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 một 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 chạy để 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ừ 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 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 bình thường với mã thoát là 0, thì quy trình kiểm thử đó đã vượt qua. Mọi kết quả khác đều được coi là kiểm thử không thành công. Cụ thể, việc ghi bất kỳ chuỗi nào PASS hoặc FAIL vào stdout đều không có ý nghĩa gì đối với trình chạy kiểm thử.
Nếu một 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ì trình chạy kiểm thử có thể chọn chấm dứt 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 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 kiểm thử riêng lẻ) được cấp 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 kiểm thử 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 |
Các kiểm thử không chỉ định rõ thời gian chờ sẽ có thời gian chờ ngầm ẩn 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" với 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 kiểm thử sẽ không bị phạt vì thời gian chờ quá dài, mặc dù có thể sẽ có cảnh báo: bạn thường nên đặt thời gian chờ ngắn nhất có thể mà không gây ra 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 các đ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 cũng nên đặt 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 thông số kỹ thuật 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ể loại bỏ mọi quy trình lạc lối. Các bài kiểm thử không được rò rỉ 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 chương trình 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ạn 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ợ tính năng phân đoạn. Nếu trình chạy hỗ trợ phân đoạn, thì 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 bạn bật --incompatible_check_sharding_support, Bazel sẽ không vượt qua được 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ố điều kiện ban đầu nhất định.
Trình chạy kiểm thử phải gọi từng chương trình 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 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 một 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 |
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 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 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 (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 bạn sử dụng tuỳ chọn --runs_per_test, thì TEST_RUN_NUMBER 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_TARGET |
Tên của mục tiêu đang được kiểm thử | 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 bạn sử dụng sharding |
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 tệp chạy | bắt buộc |
TEST_TOTAL_SHARDS |
tổng số shard count, nếu bạn sử dụng sharding |
tùy chọn |
TEST_TMPDIR |
đường dẫn tuyệt đối đến 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 có thể ghi (dùng để ghi đầ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 (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 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 hành động 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 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 điều khiển |
bắt buộc |
Môi trường có thể chứa các mục bổ sung. 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. Quy trình có thể là hoặc không phải là trưởng nhóm quy trình hoặc trưởng phiên. Quy trình 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 quy trình con đang chạy hoặc chưa được thu hoạch. Quy trình 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 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ự. Các luồng này có thể chia sẻ một mục nhập trong bảng tệp mở (nghĩa là các luồng này 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.
Umask ban đầu phải 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ả 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ề) không được chỉ định.
Chính sách lên lịch và mức độ ưu tiên 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à 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.
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 hoạt động. 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 phải có thể ghi, nhưng các bài kiểm thử nên tránh sử dụng các đường dẫn này.
Các bài kiểm thử không được giả định rằng có bất kỳ đường dẫn hằng số nào để sử dụng riêng.
Các chương trình kiểm thử không được giả định rằng atimes được bật cho bất kỳ hệ thống tệp nào được gắn.
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.
Bạn phải thực thi kiểm thử dưới dạng 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ự 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. Không 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 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. Bạn có thể không ghi được vào tệp này. Các chương trình kiểm thử không được cố gắng ghi vào đó.
Nối mạng
Chưa chỉ định tên máy chủ. Tên này 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 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 chương trình kiểm thử được cấp ít nhất một lõi CPU. Các ngôn ngữ khác có thể được hỗ trợ nhưng không được đảm bảo. Các khía cạnh hiệu suất khác của nhân này không được chỉ đị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ột máy có tổng số lõi CPU ít hơn số lõi được 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à một chương trình kiểm thử có thể sử dụng. Giới hạn này có thể thay đổi, nhưng hiện đang ở mức 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ờ của 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 máy chủ X phải khởi động 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.
Các chương trình 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 cố gắng 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 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 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, đồng thời 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à 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 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 các khung này ngay cả khi chúng tạo tệp bên ngoài TEST_TMPDIR.
Các chương trình 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 cho việc cung cấp tệp đầu vào.
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 được 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 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 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 đó, thư mục làm việc ban đầu không được ghi được.) Các chương trình kiểm thử không được giả định rằng bất kỳ phần nào của tệp chạy đều có thể ghi hoặc thuộc quyền 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 tệp chạy (bao gồm cả các đường dẫn đi qua đường liên kết tượng trưng) không được thay đổi trong quá trình thực thi kiểm thử. Thư mục gốc 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 trường hợp thoát sớm, một chương 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 khởi động và xoá tệp đó 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 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 trên thuộc tính tags.
| Thẻ | Ý nghĩa |
|---|---|
exclusive |
không chạy bất kỳ kiểm thử nào khác cùng lúc |
external |
kiểm thử có phần phụ thuộc bên ngoài; tắt tính năng lưu vào bộ nhớ đệm kiểm thử |
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 |
Tệp chạy
Trong phần 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 trên quy tắc có nhãn //deps/server:server.
Vị trí
Thư mục runfiles cho một 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à 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 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 của thời gian biên dịch hoặc thời gian chạy. 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 tệp 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 đườ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/servervà đườ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. - Đườ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 đườ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 dùng chung một thư mục runfiles.