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

Báo cáo vấn đề Xem nguồn Nightly .

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

Thông tin khái quát

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

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

Người dùng cũng có thể trực tiếp thực thi các tệp nhị phân kiểm thử. Điều này được 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 uỷ nhiệm được mô tả bên dưới.

Các bài kiểm thử phải có chế độ ẩn: tức là chỉ nên truy cập vào những tài nguyên có phần phụ thuộc được khai báo trên đó. Nếu thử nghiệm không được đóng gói đúng cách, thì chúng sẽ không cung cấp kết quả có thể tái lập trước đây. Đây có thể là vấn đề quan 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 kiểm thử), kiểm thử kỹ thuật của bản phát hành và tách biệt tài nguyên kiểm thử (khung kiểm thử tự động không nên DDOS trên máy chủ vì một số kiểm thử 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. Đối tượng 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 của 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, từ đó giúp cơ sở hạ tầng kiểm thử được tự do hơn để thực hiện các thay đổi về cách triển khai. 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 hoạt động kiểm thử vượt qua mặc dù không được khép kín, tất định và lặp lại đúng cách.

Trang này nhằm mục đích cung cấp nội dung quy chuẩn vừa có căn cứ đáng tin. 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 được đề xuất

Các từ khoá "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 như mô tả trong IETF RFC 2119.

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 đượ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ử, dữ liệu đầu ra vàng và mọi nội dung khác được quản lý theo phiên bản.) Một người dùng viết một kiểm thử để xác nhận một giá trị bất biến mà họ muốn duy trì. Những người dùng khác thực thi bài kiểm thử vào lúc khác để kiểm tra xem giá trị bất biến đã bị hỏng hay chưa. 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 dạng ngắt quãng), thì giá trị của chương trình sẽ giảm đi vì người dùng sau này không thể chắc chắn các thay đổi của họ có lỗi khi kiểm thử ngừng đạt.

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

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

Hiện tại, chúng tôi không thực thi hành vi như vậy. Tuy nhiên, trình chạy kiểm thử vẫn giữ quyền thêm loại 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ử tương tự như các quy tắc nhị phân, trong đó mỗi quy tắc phải mang lại một 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 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 của runfile, tệp đầu vào đượ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. (Dữ liệu này có thể được dùng như một cách 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ẻ 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 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 cố định giá trị trong mã đến 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 lượt 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 quy 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à có căn cứ đáng tin. Nếu một quy trình kiểm thử chạy đến khi hoàn tất và kết thúc như bình thường bằng mã thoát bằng 0, thì 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ử. Cụ thể, việc ghi bất kỳ chuỗi PASS hoặc FAIL nào vào stdout không có ý nghĩa gì đối với trình chạy kiểm thử.

Nếu một chương trình 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 nếu trình chạy kiểm thử phát hiện hành vi bị cấm, thì có thể chọn dừng kiểm thử và coi quá trình chạy đó là không thành công. 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ỳ phần tử con nào của quá trình đó.

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 cung 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 hoạt động kiểm thử không chỉ định rõ thời gian chờ được ngụ ý dựa trên size của hoạt động kiểm thử như sau:

size Nhãn thời gian chờ ngụ ý
nhỏ ngắn
trung bình vừa
lớn long
to 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. Quá trình kiểm thử "trung bình" có thời gian chờ là "ngắn" sẽ được phân bổ trong 60 giây.

Không giống như timeout, size cũng xác định thêm mức sử dụng cao nhất 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 phổ biến.

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

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

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 xác định 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 2 phút.

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

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

Ví dụ: nếu một quy trình kiểm thử "trung bình" hoàn tất sau 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 --test_verbose_timeout_warnings bazel sẽ hiển thị các 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 thông số kỹ thuật tại đây. Nếu không được chỉ định, kích thước của kiểm thử sẽ được 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ố phần tử con của quy trình đó vẫn đang chạy, thì trình chạy kiểm thử nên coi 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 quan sát được từ quy trình chính. Trình chạy kiểm thử này có thể loại bỏ mọi quá trình bị gián đoạ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ử. Hãy xem --test_sharding_strategy và shard_count để bật tính năng phân đoạn kiểm thử. 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. Người chạy sử dụng thông tin này để chọn những loạ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 hỗ trợ tính năng phân đoạn, thì trình chạy phải tạo hoặc cập nhật ngày sửa đổi 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 được quy trình 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 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à tương đối và nằm bên dưới thư mục hiện tại của chương trình kiểm thử (nằm trong cây chạy tệp, hãy 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 quy trình 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ẽ bao gồm như sau:

Biến Giá trị Trạng thái
HOME giá trị của $TEST_TMPDIR được đề xuất
LANG huỷ đặt bắt buộc
LANGUAGE huỷ đặt bắt buộc
LC_ALL huỷ đặt bắt buộc
LC_COLLATE huỷ đặt bắt buộc
LC_CTYPE huỷ đặt bắt buộc
LC_MESSAGES huỷ đặt bắt buộc
LC_MONETARY huỷ đặt bắt buộc
LC_NUMERIC huỷ đặt bắt buộc
LC_TIME huỷ đặt bắt buộc
LD_LIBRARY_PATH danh sách các thư mục được phân tách bằng dấu hai chấm chứa thư viện dùng chung 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 (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à một cơ chế chung để báo cáo các lỗi kiểm thử không ổn định. Trong trường hợp này, cơ sở hạ tầng kiểm thử được định nghĩa là các hệ thống hoặc thư viện không dành riêng cho kiểm thử nhưng có thể gây ra thất bại trong kiểm thử do 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ý bộ đệm prob Splitter) 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 để phát hiện các 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, thì 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ử riêng lẻ. không bắt buộc
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 bằng 1) cho mỗi lần chạy kiểm thử riêng lẻ. 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 trong vài giây không bắt buộc
TEST_SHARD_INDEX chỉ mục phân đoạn, nếu sharding được sử dụng không bắt buộc
TEST_SHARD_STATUS_FILE đường dẫn đến tệp sẽ chạm vào để cho biết có hỗ trợ sharding không bắt buộc
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 không bắt buộc
TEST_TMPDIR đường dẫn tuyệt đối đến thư mục riêng có thể ghi bắt buộc
TEST_WORKSPACE tên không gian làm việc của kho lưu trữ cục bộ không bắt buộc
TEST_UNDECLARED_OUTPUTS_DIR đường dẫn tuyệt đối đến một thư mục riêng tư có thể ghi (dùng để ghi các kết quả kiểm thử chưa đượ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 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ử chưa khai báo .part và .pb). 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 để ghi cảnh báo 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ử 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 sẽ gói nhật ký kiểm thử trong thao tác 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 Cho biết tệp thực thi kiểm thử đang được bazel test thúc đẩy bắt buộc

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

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

Mã tiến trình hiện tại, mã nhóm tiến trình, mã phiên và mã tiến trình chính không được chỉ định. Quá trình này có thể là trưởng nhóm quy trình hoặc trưởng phiên. Quá trình này có thể có hoặc không có thiết bị đầu cuối điều khiển. Quy 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 thu thập. Quy trình không nên có nhiều luồng khi mã kiểm thử được kiểm soát.

Chỉ số mô tả tệp 0 (stdin) sẽ mở để đọc, nhưng nội dung được đính kèm thì không được chỉ định. Không được đọc kiểm thử từ đó. Chỉ số mô tả tệp 1 (stdout) và 2 (stderr) sẽ mở để ghi, nhưng nội dung đính kèm sẽ không được chỉ định. Đó có thể là một thiết bị đầu cuối, một dấu sổ thẳng, một tệp thông thường hoặc bất kỳ nội dung nào khác có thể viết được ký tự. Họ có thể chia sẻ một mục trong bảng tệp đang mở (nghĩa là họ không thể tìm kiếm một cách độc lập). Các hoạt động kiểm thử không nên kế thừa bất cứ chỉ số mô tả tệp đang 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 bộ tính giờ khoảng thời gian nào đang chờ xử lý.

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

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

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

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

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

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

Ngoài các khía cạnh về bối cảnh của người dùng dưới sự kiểm soát trực tiếp của trình chạy kiểm thử, hệ điều hành mà kiểm thử thực thi phải đáp ứng một số thuộc tính nhất định để 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 kết.

Tất cả các công cụ xây dựng phải có tại các đường dẫn tuyệt đối trong /usr mà 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. Quy 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.

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

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

Phải tồn tại thư mục gốc, nobody và unittest của người dùng. Nhóm gốc, không ai và 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ư 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 đều chưa được chỉ định. Tập hợp mã nhóm bổ sung không được chỉ định.

Mã nhận dạng người dùng và mã nhóm hiện tại phải có cá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. Kiểm thử không được tìm cách ghi vào đó.

Mạng

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

Tài nguyên khác

Các bài kiểm thử được cấp ít nhất một lõi CPU. Các mã khác có thể có nhưng điều này không được đảm bảo. Các khía cạnh khác về hiệu suất của lõi này chưa được xác định. Bạn có thể tăng mức đặt trước lên số lượng lõi CPU cao hơn bằng cách thêm thẻ "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 ít hơn mức 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 trước số lượng lõi CPU được chỉ định ở đây.

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

Có giới hạn về số lượng tệp đầu vào mà chương trình kiểm thử có thể sử dụng. Giới hạn này 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.

X Windows có thể chạy hoặc không. Các chương trình kiểm thử cần có máy chủ X sẽ 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 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ó quy định khác.

Chương trình 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.

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 hoạt động kiểm thử cũng có thể ghi tệp .part vào $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR để chú giải các tệp đầu ra chưa được khai báo.

Trong một số ít trường hợp, chương trình kiểm thử có thể buộc phải tạo tệp trong /tmp. Ví dụ: giới hạn độ dài đường dẫn cho cổng miền Unix thường yêu cầu tạo ổ cắm trong /tmp. Bazel sẽ không thể theo dõi các tệp như vậy; bản thân quy trình kiểm thử phải chú ý đảm bảo tính kín, sử dụng các đường dẫn duy nhất để tránh va chạm với các tệp 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 được 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 có chức năng dọn dẹp các tệp trong /tmp, vì vậy, bạn có thể dùng các khung này ngay cả khi các khung này tạo tệp bên ngoài TEST_TMPDIR.

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 dành riêng để cung cấp tệp đầu vào.

Các bài 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 luận từ vị trí của tệp thực thi của chính chúng.

Không xác định được cây runfile chứa tệp thông thường, đường liên kết tượng trưng hay hỗn hợp. 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 chạy tệp chạy trong quá trình kiểm thử.

Không có thư mục, tệp hoặc đường liên kết tượng trưng nào trong cây runfile (bao gồm cả các đường dẫn chứa đường liên kết tượng trưng đi ngang) có thể ghi. (Theo đó, thư mục làm việc ban đầu không được ghi.) Quá trình 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ể bị lỗi).

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

Để phát hiện lượt 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 nhìn thấy tệp khi quá trình kiểm thử kết thúc, Bazel sẽ cho rằng chương trình kiểm thử đã thoát sớm và đánh dấu là không thành công.

Quy ước về thẻ

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

Gắn 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 hoạt động kiểm thử vào bộ nhớ đệm
large Quy ước test_suite; bộ các thử nghiệm lớn
manual * không bao gồm mục tiêu thử nghiệm trong các mẫu mục tiêu ký tự đại diện như :..., :* hoặc :all
medium Quy ước test_suite; bộ kiểm thử trung bình
small Quy ước test_suite; bộ các kiểm thử nhỏ
smoke Quy ước test_suite; nghĩa là phải chạy trước khi xác nhận các thay đổi mã vào hệ thống quản lý phiên bản

Tệp chạy

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

Vị trí

Thư mục runfile của //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 runfile đượ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 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 thư mụ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 việc tạo lại.

Nội dung

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

  • Liên kết đến các phần phụ thuộc trong thời gian chạy: mỗi OutputFile và CommandRule là phần phụ thuộc thời gian chạy của quy tắc *_binary() được biểu thị bằng một đường liên kết tượng trưng trong thư mục runfile. Tên của đườ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 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 runfile của C đến các 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 runfile. Ví dụ: tất cả các chương trình con đều có chung một thư mục runfile.