Spesifikasi lengkap tentang lingkungan eksekusi uji.
Latar belakang
Bahasa Bazel BUILD mencakup aturan yang dapat digunakan untuk menentukan menguji program dalam banyak bahasa.
Pengujian dijalankan menggunakan bazel test.
Pengguna juga dapat menjalankan biner pengujian secara langsung. Hal ini diizinkan tetapi tidak didukung, sehingga pemanggilan semacam itu tidak akan mematuhi mandat yang dijelaskan di bawah.
Pengujian harus bersifat hermetik: yaitu pengujian harus mengakses resource tersebut saja tempat mereka memiliki dependensi yang dideklarasikan. Jika pengujian tidak tertutup dengan benar maka mereka tidak memberikan hasil yang dapat direproduksi secara historis. Hal ini dapat berupa signifikan untuk penemuan penyebab (menentukan perubahan mana yang merusak tes), kemampuan audit teknis rilis, dan isolasi resource pengujian (otomatis tidak boleh melakukan DDOS server karena beberapa tes kebetulan berkomunikasi dengan itu).
Tujuan
Tujuan halaman ini adalah untuk secara resmi menetapkan lingkungan runtime untuk dan perilaku yang diharapkan dari pengujian Bazel. Hal ini juga akan menerapkan persyaratan pada pengujian runner dan sistem build.
Spesifikasi lingkungan pengujian membantu penulis pengujian menghindari mengandalkan perilaku yang tidak ditentukan, dan dengan demikian memberikan infrastruktur pengujian lebih kebebasan untuk membuat perubahan implementasi. Spesifikasi memperketat beberapa lubang yang memungkinkan banyak tes untuk lulus meskipun tidak tertutup dengan benar, determenistik, dan reentrant.
Halaman ini dimaksudkan untuk bersifat normatif dan otoritatif. Jika ini spesifikasi dan perilaku yang diimplementasikan dari {i>test runner<i} tidak setuju, spesifikasi lebih diutamakan.
Spesifikasi yang Diusulkan
Kata kunci "HARUS", "TIDAK BOLEH", "DIPERLUKAN", "TIDAK BOLEH", "TIDAK BOLEH", "Seharusnya", "TIDAK BOLEH", "DIREKOMENDASIKAN", "MEI", dan "OPSIONAL" harus ditafsirkan sebagai yang dijelaskan dalam IETF RFC 2119.
Tujuan pengujian
Tujuan pengujian Bazel adalah untuk mengkonfirmasi beberapa properti file sumber yang masuk ke dalam repositori. (Di halaman ini, "file sumber" mencakup data pengujian, output emas, dan apa pun yang berada di bawah kontrol versi.) Satu pengguna menulis untuk menyatakan invarian yang diharapkan untuk dipertahankan. Pengguna lain jalankan pengujian nanti untuk memeriksa apakah invarian telah rusak. Jika pengujian bergantung pada variabel apa pun selain file sumber (non-hermetik), nilainya berkurang, karena pengguna di kemudian hari tidak dapat memastikan bahwa perubahan yang mereka lakukan salah saat pengujian berhenti lulus.
Oleh karena itu, hasil pengujian hanya boleh bergantung pada:
- file sumber tempat pengujian memiliki dependensi yang dideklarasikan
- produk sistem build tempat pengujian memiliki dependensi yang dideklarasikan
- resource yang perilakunya dijamin oleh runner pengujian untuk tetap konstan
Saat ini, perilaku tersebut tidak diterapkan. Namun, {i>test runner<i} mencadangkan hak untuk menerapkan penegakan kebijakan tersebut di masa mendatang.
Peran sistem build
Aturan pengujian analog dengan aturan biner, di mana masing-masing aturan harus menghasilkan file yang dapat dieksekusi program ini. Untuk beberapa bahasa, ini adalah program rintisan yang menggabungkan porta khusus bahasa dengan kode pengujian. Aturan pengujian harus menghasilkan output juga. Selain pengujian utama yang dapat dieksekusi, runner pengujian akan memerlukan manifes runfiles, file input yang harus disediakan ke pengujian saat runtime, dan mungkin memerlukan informasi tentang jenis, ukuran, dan tag suatu pengujian.
Sistem build dapat menggunakan runfile untuk mengirimkan kode serta data. (Ini dapat digunakan sebagai pengoptimalan untuk membuat setiap biner pengujian menjadi lebih kecil dengan membagikan di seluruh pengujian, seperti melalui penggunaan penautan dinamis.) Sistem build harus memastikan bahwa {i>executable<i} yang dihasilkan memuat file ini melalui {i>runfile<i} gambar yang disediakan oleh runner pengujian, bukan referensi yang di-hardcode agar lokasi di hierarki sumber atau output.
Peran runner pengujian
Dari sudut pandang {i>test runner<i}, setiap tes adalah
program yang dapat
dipanggil dengan execve(). Mungkin ada cara lain untuk menjalankan pengujian; misalnya,
IDE memungkinkan pelaksanaan pengujian Java dalam proses. Namun, hasil yang
menjalankan tes sebagai proses
mandiri harus dianggap otoritatif. Jika
proses pengujian berjalan sampai selesai dan berakhir secara normal dengan {i>exit code<i}
nol, berarti pengujian telah lulus. Hasil lainnya dianggap gagal pengujian. Di beberapa
khususnya, menulis salah satu string PASS atau FAIL ke {i>stdout<i} tidak memiliki
penting bagi runner pengujian.
Jika pengujian membutuhkan waktu terlalu lama untuk dijalankan, melebihi batas resource, atau pengujian jika tidak mendeteksi perilaku yang dilarang, {i>runner<i} dapat memilih untuk menghentikan pengujian dan memperlakukan proses sebagai kegagalan. Runner tidak boleh melaporkan pengujian sebagai lulus setelah mengirimkan sinyal ke proses pengujian atau turunannya.
Seluruh target pengujian (bukan metode atau pengujian individual) diberi batasan
lama waktu untuk beroperasi hingga penyelesaian. Batas waktu pengujian didasarkan pada
Atribut timeout menurut
pada tabel berikut:
| timeout | Batas Waktu (dtk) |
|---|---|
| short | 60 |
| sedang | 300 |
| long | 900 |
| abadi | 3600 |
Pengujian yang tidak secara eksplisit menetapkan waktu tunggu memiliki waktu tunggu tersirat berdasarkan
size pengujian sebagai berikut:
| ukuran | Label waktu tunggu tersirat |
|---|---|
| small | short |
| sedang | sedang |
| large | long |
| sangat besar | abadi |
Gambar "besar" pengujian tanpa setelan waktu tunggu eksplisit akan dialokasikan 900 detik untuk berlari. "Media" pengujian dengan waktu tunggu "short" akan dialokasikan 60 detik.
Tidak seperti timeout, size juga menentukan asumsi penggunaan puncak
resource lain (seperti RAM) saat menjalankan pengujian secara lokal, seperti yang dijelaskan dalam
Definisi umum.
Semua kombinasi dari label size dan timeout bersifat legal, sehingga label yang "sangat besar" uji
dapat dideklarasikan memiliki waktu tunggu "short". Mungkin itu akan melakukan
mengerikan dengan sangat cepat.
Pengujian dapat ditampilkan dengan cepat secara arbitrer terlepas dari waktu tunggunya. Tes tidak diberi sanksi untuk waktu tunggu yang terlalu banyak, meskipun peringatan mungkin dikeluarkan: Anda harus umumnya menyetel waktu tunggu seketat mungkin tanpa menimbulkan kegagalan.
Waktu tunggu pengujian dapat diganti dengan tanda bazel --test_timeout jika
yang berjalan secara manual dalam
kondisi yang diketahui lambat. Tujuan
Nilai --test_timeout dalam detik. Misalnya, --test_timeout=120
menetapkan waktu tunggu pengujian menjadi dua menit.
Ada juga batas bawah yang direkomendasikan untuk waktu tunggu pengujian seperti berikut:
| timeout | Waktu minimum (dtk) |
|---|---|
| short | 0 |
| sedang | 30 |
| long | 300 |
| abadi | 900 |
Misalnya, jika skor "menengah" pengujian selesai dalam 5,5 detik, pertimbangkan untuk menyetel timeout =
"short" atau size = "small". Menggunakan bazel --test_verbose_timeout_warnings
akan menampilkan pengujian yang ukuran yang ditetapkan terlalu besar.
Ukuran dan waktu tunggu pengujian ditentukan dalam file BUILD sesuai dengan spesifikasinya di sini. Jika tidak ditentukan, ukuran pengujian akan ditetapkan secara default ke "medium".
Jika proses utama pengujian keluar, tetapi beberapa turunannya masih berjalan, pelari pengujian harus menganggap bahwa {i>run<i} telah selesai dan menghitungnya sebagai sukses atau kegagalan berdasarkan {i>exit code<i} yang diamati dari proses utama. Runner pengujian dapat membunuh proses yang menyimpang. Pengujian tidak boleh membocorkan proses dengan cara ini.
Sharding pengujian
Pengujian dapat diparalelkan melalui sharding pengujian. Lihat
--test_sharding_strategy dan
shard_count untuk mengaktifkan
sharding pengujian. Saat sharding diaktifkan, runner pengujian diluncurkan sekali setiap
sharding. Variabel lingkungan TEST_TOTAL_SHARDS adalah
jumlah shard, dan TEST_SHARD_INDEX adalah shard
indeks, dimulai dari 0. Pelari menggunakan informasi ini
untuk memilih pengujian yang akan
dijalankan - misalnya, menggunakan strategi round-robin. Tidak semua runner pengujian mendukung
sharding data. Jika runner mendukung sharding, runner harus membuat atau memperbarui
perubahan tanggal file yang ditentukan oleh
TEST_SHARD_STATUS_FILE Sebaliknya, jika
--incompatible_check_sharding_support
diaktifkan, Bazel akan gagal dalam pengujian jika di-sharding.
Kondisi awal
Saat menjalankan pengujian, runner pengujian harus menetapkan kondisi tertentu.
Runner pengujian harus memanggil setiap pengujian dengan jalur ke pengujian yang dapat dieksekusi di
argv[0]. Jalur ini harus relatif dan berada di bawah direktori pengujian saat ini
(yang ada di hierarki runfiles, lihat di bawah). Runner pengujian tidak boleh lulus
argumen lain untuk pengujian kecuali pengguna
secara eksplisit memintanya.
Blok lingkungan awal harus disusun sebagai berikut:
| Variabel | Nilai | Status |
|---|---|---|
HOME |
nilai $TEST_TMPDIR |
disarankan |
LANG |
tidak ditetapkan | wajib diisi |
LANGUAGE |
tidak ditetapkan | wajib diisi |
LC_ALL |
tidak ditetapkan | wajib diisi |
LC_COLLATE |
tidak ditetapkan | wajib diisi |
LC_CTYPE |
tidak ditetapkan | wajib diisi |
LC_MESSAGES |
tidak ditetapkan | wajib diisi |
LC_MONETARY |
tidak ditetapkan | wajib diisi |
LC_NUMERIC |
tidak ditetapkan | wajib diisi |
LC_TIME |
tidak ditetapkan | wajib diisi |
LD_LIBRARY_PATH |
daftar direktori yang dipisahkan titik dua yang berisi library bersama | opsional |
JAVA_RUNFILES |
nilai $TEST_SRCDIR |
tidak digunakan lagi |
LOGNAME |
nilai $USER |
wajib diisi |
PATH |
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. |
direkomendasikan |
PWD |
$TEST_SRCDIR/workspace-name |
direkomendasikan |
SHLVL |
2 |
disarankan |
TEST_INFRASTRUCTURE_FAILURE_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (File ini sebaiknya hanya digunakan untuk melaporkan kegagalan yang berasal dari pengujian infrastruktur IT, bukan sebagai mekanisme umum untuk melaporkan kegagalan yang tidak stabil pengujian. Dalam konteks ini, infrastruktur pengujian didefinisikan sebagai sistem atau library yang tidak spesifik untuk pengujian, tetapi dapat menyebabkan kegagalan uji gagal berfungsi. Baris pertama adalah nama infrastruktur pengujian komponen yang menyebabkan kegagalan, komponen kedua adalah deskripsi kegagalan. Baris tambahan akan diabaikan.) | opsional |
TEST_LOGSPLITTER_OUTPUT_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk menulis Log protobuffer pemisah log) | opsional |
TEST_PREMATURE_EXIT_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk
menangkap panggilan ke exit()) |
opsional |
TEST_RANDOM_SEED |
Jika opsi --runs_per_test digunakan,
TEST_RANDOM_SEED disetel ke run number
(dimulai dengan 1) untuk setiap pengujian. |
opsional |
TEST_RUN_NUMBER |
Jika opsi --runs_per_test digunakan,
TEST_RUN_NUMBER disetel ke run number
(dimulai dengan 1) untuk setiap pengujian. |
opsional |
TEST_TARGET |
Nama target yang diuji | opsional |
TEST_SIZE |
Pengujian size |
opsional |
TEST_TIMEOUT |
Pengujian timeout dalam hitungan detik |
opsional |
TEST_SHARD_INDEX |
indeks shard, jika sharding digunakan |
opsional |
TEST_SHARD_STATUS_FILE |
jalur ke file yang akan disentuh untuk menunjukkan dukungan bagi sharding |
opsional |
TEST_SRCDIR |
jalur absolut ke dasar hierarki runfiles | wajib diisi |
TEST_TOTAL_SHARDS |
total
shard count,
jika sharding digunakan |
opsional |
TEST_TMPDIR |
jalur absolut ke direktori pribadi yang dapat ditulis | wajib diisi |
TEST_WORKSPACE |
nama ruang kerja repositori lokal | opsional |
TEST_UNDECLARED_OUTPUTS_DIR |
jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis perintah output pengujian) | opsional |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR |
jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis perintah
menguji anotasi output file .part dan .pb). |
opsional |
TEST_WARNINGS_OUTPUT_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk menulis peringatan target pengujian) | opsional |
TESTBRIDGE_TEST_ONLY |
nilai
--test_filter,
jika ditentukan |
opsional |
TZ |
UTC |
wajib diisi |
USER |
nilai getpwuid(getuid())->pw_name |
wajib diisi |
XML_OUTPUT_FILE |
Lokasi tempat tindakan pengujian harus menulis file output XML hasil pengujian. Jika tidak, Bazel akan menghasilkan file output XML default yang menggabungkan log pengujian sebagai bagian dari tindakan pengujian. Skema XML didasarkan pada Skema hasil pengujian JUnit. | opsional |
BAZEL_TEST |
Menunjukkan bahwa pengujian yang dapat dieksekusi didorong oleh bazel test |
wajib diisi |
Lingkungan dapat berisi entri tambahan. Pengujian tidak boleh bergantung pada kehadiran, ketidakhadiran, atau nilai dari variabel lingkungan apa pun yang tidak tercantum di atas.
Direktori kerja awal harus $TEST_SRCDIR/$TEST_WORKSPACE.
Id proses, id grup proses, id sesi, dan id proses induk saat ini adalah belum ditetapkan. Prosesnya mungkin atau mungkin bukan pemimpin kelompok proses atau sesi pemimpin. Proses ini mungkin atau mungkin tidak memiliki terminal pengendali. Proses ini mungkin memiliki nol atau lebih proses turunan yang berjalan atau tidak dijalankan. Proses ini tidak boleh memiliki beberapa thread saat kode pengujian mendapatkan kontrol.
Deskriptor file 0 (stdin) harus terbuka untuk dibaca, tetapi apa yang dilampirkan
tidak ditentukan. Pengujian tidak boleh membacanya. Deskriptor file 1 (stdout) dan 2
(stderr) akan terbuka untuk penulisan, tetapi apa yang dilampirkan pada
belum ditetapkan. Itu bisa berupa terminal, pipa, file biasa, atau apa pun untuk
karakter mana yang
dapat ditulis. Mereka dapat berbagi
entri dalam tabel {i>file<i} yang terbuka
(artinya tidak dapat mencari secara mandiri). Pengujian tidak boleh mewarisi
deskriptor file terbuka lainnya.
Umask awal harus 022 atau 027.
Tidak ada timer alarm atau timer interval yang akan tertunda.
Masker awal dari sinyal yang diblokir harus kosong. Semua sinyal harus ditetapkan ke tindakan default-nya.
Batas resource awal, baik lembut maupun keras, harus disetel sebagai berikut:
| Resource | Batas |
|---|---|
RLIMIT_AS |
tak terbatas |
RLIMIT_CORE |
belum ditetapkan |
RLIMIT_CPU |
tak terbatas |
RLIMIT_DATA |
tak terbatas |
RLIMIT_FSIZE |
tak terbatas |
RLIMIT_LOCKS |
tak terbatas |
RLIMIT_MEMLOCK |
tak terbatas |
RLIMIT_MSGQUEUE |
belum ditetapkan |
RLIMIT_NICE |
belum ditetapkan |
RLIMIT_NOFILE |
setidaknya 1024 |
RLIMIT_NPROC |
belum ditetapkan |
RLIMIT_RSS |
tak terbatas |
RLIMIT_RTPRIO |
belum ditetapkan |
RLIMIT_SIGPENDING |
belum ditetapkan |
RLIMIT_STACK |
tidak terbatas, atau 2044KB <= rlim <= 8192KB |
Waktu proses awal (seperti yang ditampilkan oleh times()) dan pemanfaatan resource
(seperti yang ditampilkan oleh getrusage()) tidak ditentukan.
Kebijakan dan prioritas penjadwalan awal tidak ditentukan.
Peran sistem host
Selain aspek konteks pengguna di bawah kontrol langsung pengujian sistem operasi tempat pengujian dijalankan harus memenuhi persyaratan agar pengujian menjadi valid.
Filesystem
Direktori {i>root<i} yang diamati oleh pengujian mungkin atau mungkin bukan direktori {i>root<i} asli.
/proc harus dipasang.
Semua alat build harus ada di jalur absolut pada /usr yang digunakan oleh
instalasi lokal.
Jalur yang dimulai dengan /home mungkin tidak tersedia. Pengujian tidak boleh mengakses
jalur tersebut.
/tmp harus dapat ditulis, tetapi pengujian harus menghindari penggunaan jalur ini.
Pengujian tidak boleh berasumsi bahwa setiap jalur konstan tersedia untuk gunakan.
Pengujian tidak boleh berasumsi bahwa waktu diaktifkan untuk sistem file yang terpasang.
Pengguna dan grup
Root pengguna, tidak ada seorang pun, dan unittest harus ada. Grup {i>root<i}, {i>nobody<i}, dan eng harus ada.
Pengujian harus dijalankan sebagai pengguna non-root. ID pengguna yang sebenarnya dan efektif harus sama; juga untuk ID grup. Di luar ini, id pengguna saat ini, id grup, nama pengguna, dan nama grup tidak ditentukan. Kumpulan ID grup tambahan belum ditetapkan.
Id pengguna dan id grup saat ini harus memiliki nama yang sesuai yang dapat
diambil dengan getpwuid() dan getgrgid(). Hal yang sama mungkin
tidak berlaku untuk
ID grup tambahan.
Pengguna saat ini harus memiliki direktori {i>home<i}. Dokumen ini mungkin tidak dapat ditulis. Pengujian harus tidak mencoba menulisnya.
Networking
Nama host tidak ditentukan. Kolom ini mungkin berisi atau tidak berisi titik. Menyelesaikan {i>host <i}harus memberikan alamat IP dari {i>host<i} saat ini. Menyelesaikan masalah nama host yang terpotong setelah titik pertama juga harus dapat berfungsi. Nama host {i>localhost<i} harus di-resolve.
Referensi lainnya
Pengujian diberikan setidaknya satu core CPU. Domain lain mungkin tersedia, tetapi tidak tersedia dijamin efektif. Aspek performa lain dari inti ini tidak ditentukan. Anda dapat meningkatkan reservasi ke jumlah inti CPU yang lebih tinggi dengan menambahkan tag "cpu:n" (dengan n adalah bilangan positif) ke aturan pengujian. Jika mesin memiliki lebih sedikit dengan total inti CPU lebih dari yang diminta, Bazel akan tetap menjalankan pengujian. Jika suatu pengujian menggunakan sharding, setiap shard akan mencadangkan jumlah CPU atau core yang ditentukan di sini.
Pengujian dapat membuat subproses, tetapi tidak dapat memproses grup atau sesi.
Ada batas jumlah file input yang dapat digunakan oleh pengujian. Batas ini dapat berubah sewaktu-waktu, tetapi saat ini inputnya berada dalam rentang puluhan ribu.
Waktu dan tanggal
Waktu dan tanggal saat ini tidak ditentukan. Zona waktu sistem tidak ditentukan.
X Windows mungkin tersedia atau tidak. Pengujian yang memerlukan server X harus dimulai Xvfb.
Menguji interaksi dengan sistem file
Semua jalur file yang ditentukan dalam variabel lingkungan pengujian menunjuk ke suatu tempat dalam sistem file lokal, kecuali dinyatakan lain.
Pengujian harus membuat file hanya dalam direktori yang ditentukan oleh
$TEST_TMPDIR dan $TEST_UNDECLARED_OUTPUTS_DIR (jika ditetapkan).
Direktori ini awalnya akan kosong.
Pengujian tidak boleh mencoba menghapus, melakukan chmod, atau mengubah direktori ini.
Direktori ini mungkin berupa tautan simbolis.
Jenis sistem file $TEST_TMPDIR/. masih belum ditentukan.
Pengujian juga dapat menulis file .part ke
$TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR untuk menganotasi file output yang tidak dideklarasikan.
Dalam kasus yang jarang terjadi, pengujian mungkin dipaksa untuk membuat file di /tmp. Misalnya,
batas panjang jalur untuk soket domain Unix
biasanya memerlukan pembuatan soket di bawah /tmp. Bazel tidak akan bisa
melacak file tersebut; pengujian itu sendiri harus bersifat
hermetic, agar dapat menggunakan
jalur agar tidak bertabrakan dengan yang lain, yang menjalankan pengujian dan non-pengujian secara bersamaan
proses, dan untuk membersihkan file yang dibuat di /tmp.
Beberapa framework pengujian populer, seperti
JUnit4 TemporaryFolder
atau Go TempDir, miliki
cara mereka sendiri untuk membuat
direktori sementara di /tmp. Pengujian ini
framework mencakup fungsi yang membersihkan file di /tmp, sehingga Anda dapat menggunakan
file tersebut meskipun mereka membuat file di luar TEST_TMPDIR.
Pengujian harus mengakses input melalui mekanisme runfiles, atau bagian lain dari lingkungan eksekusi yang secara khusus dimaksudkan untuk membuat file input yang tersedia.
Pengujian tidak boleh mengakses output lain dari sistem build di jalur yang disimpulkan dari lokasi file yang dapat dieksekusi.
Tidak ditentukan apakah hierarki runfiles berisi file biasa, file simbolis
tautan, atau campuran. Hierarki runfiles dapat berisi symlink ke direktori.
Pengujian harus menghindari penggunaan jalur yang berisi komponen .. dalam runfile
hierarki.
Tidak ada direktori, file, atau symlink dalam hierarki runfiles (termasuk jalur yang
{i>traverse symlink<i}) harus dapat ditulis. (Setelah itu, kerja awal
direktori tidak dapat ditulisi.) Pengujian tidak boleh mengasumsikan bahwa
runfile dapat ditulis, atau dimiliki oleh pengguna saat ini (misalnya, chmod dan chgrp dapat
gagal).
Hierarki runfiles (termasuk jalur yang melintasi symlink) tidak boleh berubah selama pelaksanaan uji. Direktori induk dan pemasangan sistem file tidak boleh berubah dengan cara apa pun yang memengaruhi hasil penyelesaian jalur dalam runfile hierarki.
Untuk menangkap exit (keluar) lebih awal, pengujian bisa membuat file di jalur yang ditentukan oleh
TEST_PREMATURE_EXIT_FILE saat mulai dan menghapusnya saat keluar. Jika Bazel melihat
setelah pengujian selesai, maka akan diasumsikan bahwa pengujian keluar sebelum waktunya dan
menandainya sebagai gagal.
Konvensi tag
Beberapa tag dalam aturan pengujian memiliki arti khusus. Lihat juga
Bazel Build Encyclopedia pada atribut tags.
| Tag | Arti |
|---|---|
exclusive |
tidak boleh menjalankan pengujian lain secara bersamaan |
external |
pengujian memiliki ketergantungan eksternal; nonaktifkan uji cache |
large |
Konvensi test_suite; serangkaian pengujian besar |
manual * |
jangan sertakan target pengujian dalam pola target karakter pengganti seperti
:..., :*, atau :all |
medium |
Konvensi test_suite; rangkaian pengujian sedang |
small |
Konvensi test_suite; serangkaian pengujian kecil |
smoke |
Konvensi test_suite; berarti harus dijalankan sebelum
melakukan perubahan kode ke dalam sistem kontrol versi |
{i>Runfile<i}
Pada contoh berikut, asumsikan ada aturan *_binary() yang diberi label
//foo/bar:unittest, dengan dependensi runtime pada aturan berlabel
//deps/server:server.
Lokasi
Direktori runfiles untuk //foo/bar:unittest target adalah direktori
$(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. Jalur ini disebut sebagai
runfiles_dir.
Dependensi
Direktori runfiles dideklarasikan sebagai dependensi waktu kompilasi dari
*_binary() aturan. Direktori runfiles itu sendiri bergantung pada set BUILD
file yang memengaruhi aturan *_binary() atau waktu kompilasi atau runtime-nya
dependensi. Memodifikasi file sumber tidak mempengaruhi struktur
{i>runfiles <i}dan tidak memicu
pembuatan ulang apa pun.
Daftar Isi
Direktori runfiles berisi hal-hal berikut:
- Symlink ke dependensi run-time: setiap OutputFile dan CommandRule yang
adalah dependensi run-time dari aturan
*_binary()direpresentasikan oleh satu {i>symlink<i} di direktori {i>runfiles<i}. Nama symlink-nya$(WORKSPACE)/package_name/rule_name. Misalnya, {i>symlink<i} untuk server akan diberi nama$(WORKSPACE)/deps/server/server, dan jalur lengkapnya akan menjadi$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. Tujuan symlink adalah OutputFileName() dari OutputFile atau CommandRule, yang dinyatakan sebagai jalur absolut. Jadi, tujuan dari symlink adalah$(WORKSPACE)/linux-dbg/deps/server/42/server. - Symlink ke sub-runfile: untuk setiap
*_binary()Z yang merupakan run-time dependensi*_binary()C, ada link kedua di runfiles direktori C ke {i> runfile<i} Z. Nama symlink-nya$(WORKSPACE)/package_name/rule_name.runfiles. Target symlink direktori {i>runfiles<i}. Misalnya, semua subprogram berbagi {i>runfile<i} yang sama saat ini.