Spesifikasi lengkap tentang lingkungan eksekusi uji.
Latar belakang
Bahasa Bazel BUILD mencakup aturan yang dapat digunakan untuk menentukan program pengujian otomatis dalam banyak bahasa.
Pengujian dijalankan menggunakan bazel test
.
Pengguna juga dapat menjalankan biner pengujian secara langsung. Hal ini diizinkan tetapi tidak didukung, sehingga pemanggilan tersebut tidak akan mematuhi mandat yang dijelaskan di bawah.
Pengujian harus bersifat hermetik: yaitu pengujian hanya boleh mengakses resource yang dependensinya telah dideklarasikan. Jika tidak tertutup dengan benar, pengujian tidak akan memberikan hasil yang dapat direproduksi secara historis. Hal ini dapat menjadi masalah yang signifikan untuk penemuan penyebab (menentukan perubahan mana yang merusak pengujian), kemampuan audit engineering rilis, dan isolasi resource pengujian (framework pengujian otomatis tidak boleh melakukan DDOS server karena beberapa pengujian kebetulan berkaitan dengan server).
Tujuan
Tujuan halaman ini adalah untuk secara resmi menetapkan lingkungan runtime dan perilaku yang diharapkan dari pengujian Bazel. Tindakan ini juga akan menerapkan persyaratan pada test runner dan sistem build.
Spesifikasi lingkungan pengujian membantu penulis pengujian menghindari ketergantungan pada perilaku yang tidak ditentukan, sehingga memberikan lebih banyak kebebasan pada infrastruktur pengujian untuk melakukan perubahan implementasi. Spesifikasi ini memperketat beberapa lubang yang saat ini memungkinkan banyak pengujian lulus meskipun tidak bersifat hermetik, determenistik, dan reentrant dengan benar.
Halaman ini dimaksudkan untuk bersifat normatif dan otoritatif. Jika spesifikasi ini dan perilaku yang diterapkan dari runner pengujian tidak setuju, spesifikasi lebih diutamakan.
Spesifikasi yang Diusulkan
Kata kunci "HARUS", "HARUS NOT", "REQUIRED", "SHALL", "SHALL NOT", "SEHARUSNYA", "TIDAK BOLEH", "DIREKOMENDASIKAN", "MUNGKIN", dan "OPSIONAL" akan ditafsirkan seperti yang dijelaskan dalam RFC 2119 IETF.
Tujuan pengujian
Tujuan pengujian Bazel adalah untuk mengonfirmasi beberapa properti file sumber yang diperiksa ke dalam repositori. (Di halaman ini, "file sumber" mencakup data pengujian, output emas, dan apa pun yang berada dalam kontrol versi.) Satu pengguna menulis pengujian untuk menyatakan invarian yang ingin dipertahankan. Pengguna lain menjalankan pengujian nanti untuk memeriksa apakah invarian telah rusak. Jika pengujian bergantung pada variabel selain file sumber (non-hermetik), nilainya akan berkurang, karena pengguna selanjutnya tidak dapat memastikan bahwa perubahan mereka 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, runner pengujian berhak menambahkan penegakan tersebut di masa mendatang.
Peran sistem build
Aturan pengujian analog dengan aturan biner, yang masing-masing harus menghasilkan program yang dapat dieksekusi. Untuk beberapa bahasa, ini adalah program stub yang menggabungkan harban khusus bahasa dengan kode pengujian. Aturan pengujian juga harus menghasilkan output lainnya. Selain pengujian utama yang dapat dieksekusi, runner pengujian akan memerlukan manifes runfiles, file input yang harus tersedia untuk pengujian saat runtime, dan mungkin memerlukan informasi tentang jenis, ukuran, dan tag pengujian.
Sistem build dapat menggunakan runfile untuk mengirimkan kode serta data. (Tindakan ini dapat digunakan sebagai pengoptimalan untuk membuat setiap biner pengujian lebih kecil dengan berbagi file di seluruh pengujian, seperti melalui penggunaan penautan dinamis.) Sistem build harus memastikan bahwa file yang dapat dieksekusi yang dihasilkan memuat file tersebut melalui gambar runfile yang disediakan oleh runner pengujian, bukan referensi yang di-hardcode ke lokasi absolut dalam hierarki sumber atau output.
Peran runner pengujian
Dari sudut pandang runner pengujian, setiap pengujian adalah program yang dapat
dipanggil dengan execve()
. Mungkin ada cara lain untuk menjalankan pengujian; misalnya,
IDE mungkin mengizinkan eksekusi pengujian Java dalam proses. Namun, hasil
menjalankan pengujian sebagai proses mandiri harus dianggap otoritatif. Jika
proses pengujian berjalan hingga selesai dan berakhir secara normal dengan kode keluar
nol, berarti pengujian telah lulus. Hasil lainnya dianggap gagal pengujian. Secara
khusus, menulis salah satu string PASS
atau FAIL
ke stdout tidak
penting bagi runner pengujian.
Jika pengujian membutuhkan waktu terlalu lama untuk dijalankan, melebihi batas resource, atau runner pengujian mendeteksi perilaku yang dilarang, pengujian dapat memilih untuk menghentikan pengujian dan memperlakukan pengujian sebagai kegagalan. Runner tidak boleh melaporkan pengujian sebagai lulus setelah mengirim sinyal ke proses pengujian atau ke turunannya.
Seluruh target pengujian (bukan metode atau pengujian individual) diberi jangka waktu yang terbatas untuk dijalankan hingga selesai. Batas waktu untuk pengujian didasarkan pada
atribut timeout
sesuai
dengan tabel berikut:
timeout | Batas Waktu (dtk) |
---|---|
short | 60 |
sedang | 300 |
long | 900 |
abadi | 3.600 |
Pengujian yang tidak secara eksplisit menentukan 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 |
Pengujian "besar" tanpa setelan waktu tunggu yang eksplisit akan diberi alokasi waktu 900 detik untuk dijalankan. Pengujian "sedang" dengan waktu tunggu "singkat" akan dialokasikan selama 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 label size
dan timeout
bersifat legal, sehingga pengujian yang "sangat besar" dapat dideklarasikan memiliki waktu tunggu "singkat". Mungkin hal itu akan melakukan
hal-hal buruk dengan sangat cepat.
Pengujian dapat ditampilkan dengan cepat secara arbitrer terlepas dari waktu tunggunya. Pengujian tidak dikenai sanksi karena waktu tunggu yang terlalu lama, meskipun peringatan mungkin dikeluarkan: secara umum Anda harus menetapkan waktu tunggu seketat mungkin tanpa menimbulkan kegagalan.
Waktu tunggu pengujian dapat diganti dengan tanda bazel --test_timeout
saat
berjalan secara manual dalam kondisi yang diketahui lambat. 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 pengujian "sedang" selesai dalam 5,5 detik, pertimbangkan untuk menyetel timeout =
"short"
atau size = "small"
. Menggunakan opsi command line --test_verbose_timeout_warnings
bazel akan menampilkan pengujian yang ukuran yang ditentukan terlalu besar.
Ukuran dan waktu tunggu pengujian ditentukan dalam file BUILD sesuai dengan spesifikasi di sini. Jika tidak ditentukan, ukuran pengujian akan ditetapkan secara default ke "medium".
Jika proses utama pengujian keluar, tetapi beberapa turunannya masih berjalan, runner pengujian harus menganggap proses tersebut telah selesai dan menghitungnya sebagai berhasil atau gagal berdasarkan kode keluar yang diamati dari proses utama. Runner pengujian dapat menghentikan 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 satu kali per shard. Variabel lingkungan TEST_TOTAL_SHARDS
adalah jumlah shard, dan TEST_SHARD_INDEX
adalah indeks shard, yang dimulai dari 0. Pelari menggunakan informasi ini untuk memilih pengujian yang akan
dijalankan - misalnya, menggunakan strategi round-robin. Tidak semua runner pengujian mendukung
sharding. Jika runner mendukung sharding, runner harus membuat atau memperbarui
tanggal terakhir diubah dari file yang ditentukan oleh
TEST_SHARD_STATUS_FILE
. Jika tidak, jika
--incompatible_check_sharding_support
diaktifkan, Bazel akan gagal dalam pengujian jika di-sharding.
Kondisi awal
Saat menjalankan pengujian, runner pengujian harus menetapkan kondisi awal tertentu.
Runner pengujian harus memanggil setiap pengujian dengan jalur ke pengujian yang dapat dieksekusi di
argv[0]
. Jalur ini harus bersifat relatif dan berada di bawah direktori pengujian saat ini
(yang ada dalam hierarki runfile, lihat di bawah). Runner pengujian tidak boleh meneruskan argumen lain ke pengujian kecuali jika pengguna memintanya secara eksplisit.
Blok lingkungan awal harus disusun sebagai berikut:
Variabel | Nilai | Status |
---|---|---|
HOME |
nilai $TEST_TMPDIR |
disarankan |
LANG |
tidak ditetapkan | wajib |
LANGUAGE |
tidak ditetapkan | wajib |
LC_ALL |
tidak ditetapkan | wajib |
LC_COLLATE |
tidak ditetapkan | wajib |
LC_CTYPE |
tidak ditetapkan | wajib |
LC_MESSAGES |
tidak ditetapkan | wajib |
LC_MONETARY |
tidak ditetapkan | wajib |
LC_NUMERIC |
tidak ditetapkan | wajib |
LC_TIME |
tidak ditetapkan | wajib |
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 |
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 hanya boleh digunakan untuk melaporkan kegagalan yang berasal dari infrastruktur pengujian, bukan sebagai mekanisme umum untuk melaporkan kegagalan pengujian yang tidak stabil. Dalam konteks ini, infrastruktur pengujian didefinisikan sebagai sistem atau library yang tidak dikhususkan untuk pengujian, tetapi dapat menyebabkan kegagalan uji karena kegagalan fungsi. Baris pertama adalah nama komponen infrastruktur pengujian yang menyebabkan kegagalan, baris kedua adalah deskripsi kegagalan yang dapat dibaca manusia. Baris tambahan akan diabaikan.) | opsional |
TEST_LOGSPLITTER_OUTPUT_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk menulis log Logsplitter protobuffer) | 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 akan ditetapkan ke run number
(dimulai dengan 1) untuk setiap pengujian yang dijalankan. |
opsional |
TEST_RUN_NUMBER |
Jika opsi --runs_per_test digunakan,
TEST_RUN_NUMBER akan ditetapkan ke run number
(dimulai dengan 1) untuk setiap pengujian yang dijalankan. |
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 |
TEST_TOTAL_SHARDS |
total
shard count ,
jika sharding digunakan |
opsional |
TEST_TMPDIR |
jalur absolut ke direktori pribadi yang dapat ditulis | wajib |
TEST_WORKSPACE |
nama ruang kerja repositori lokal | opsional |
TEST_UNDECLARED_OUTPUTS_DIR |
jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis output pengujian yang tidak dideklarasikan) | opsional |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR |
jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis file .part dan .pb anotasi output pengujian yang tidak dideklarasikan). |
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 |
USER |
nilai getpwuid(getuid())->pw_name |
wajib |
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 |
Lingkungan dapat berisi entri tambahan. Pengujian tidak boleh bergantung pada keberadaan, ketidakhadiran, atau nilai 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 tidak ditentukan. Prosesnya mungkin atau mungkin bukan pemimpin grup proses atau pemimpin sesi. Proses ini mungkin atau mungkin tidak memiliki terminal pengendali. Proses tersebut mungkin memiliki nol atau beberapa proses turunan yang berjalan atau tidak menuai. Proses 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. Deskripsi file 1 (stdout
) dan 2
(stderr
) harus terbuka untuk penulisan, tetapi deskripsi file yang dilampirkan
tidak ditentukan. Dapat berupa terminal, pipa, file biasa, atau apa pun tempat karakter dapat ditulis. Pengguna mungkin berbagi entri di tabel file yang terbuka
(artinya tidak dapat mencari secara independen). 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 akan disetel ke tindakan default-nya.
Batas resource awal, baik lembut maupun keras, harus disetel sebagai berikut:
Resource | Limit |
---|---|
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 penggunaan 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 runner pengujian, sistem operasi tempat pengujian dijalankan harus memenuhi properti tertentu agar pengujian berjalan 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
penginstalan 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 penggunaan eksklusifnya.
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. Root grup, tidak ada seorang pun, dan eng harus ada.
Pengujian harus dijalankan sebagai pengguna non-root. ID pengguna yang sebenarnya dan efektif harus sama; begitu juga untuk ID grup. Selain itu, ID pengguna, ID grup, nama pengguna, dan nama grup saat ini tidak ditentukan. Kumpulan ID kelompok tambahan tidak ditentukan.
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 kelompok tambahan.
Pengguna saat ini harus memiliki direktori {i>home<i}. Dokumen ini mungkin tidak dapat ditulis. Pengujian tidak boleh mencoba menulis ke input tersebut.
Networking
Nama host tidak ditentukan. Kolom ini mungkin berisi atau tidak berisi titik. Menyelesaikan nama host harus memberikan alamat IP host saat ini. Menyelesaikan masalah nama host yang terpotong setelah titik pertama juga harus berfungsi. Nama host {i>localhost<i} harus di-resolve.
Resource lainnya
Pengujian diberikan setidaknya satu core CPU. Jenis lainnya mungkin tersedia, tetapi tidak dijamin. Aspek performa lain dari inti ini tidak ditentukan. Anda dapat meningkatkan reservasi ke jumlah inti CPU yang lebih tinggi dengan menambahkan tag "cpu:n" (n adalah angka positif) ke aturan pengujian. Jika mesin memiliki total core CPU lebih sedikit dari yang diminta, Bazel akan tetap menjalankan pengujian. Jika pengujian menggunakan sharding, setiap shard akan mencadangkan jumlah inti CPU 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 dalam rentang puluhan ribu input.
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 memulai Xvfb.
Menguji interaksi dengan sistem file
Semua jalur file yang ditentukan dalam variabel lingkungan pengujian mengarah ke suatu tempat di sistem file lokal, kecuali jika ditentukan lain.
Pengujian hanya boleh membuat file 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 pada /tmp
. Bazel tidak akan dapat
melacak file tersebut; pengujian itu sendiri harus bersifat hermetik, untuk menggunakan jalur unik
agar tidak bertabrakan dengan yang lain, menjalankan pengujian dan proses
non-pengujian secara bersamaan, serta untuk membersihkan file yang dibuat di /tmp
.
Beberapa framework pengujian populer, seperti JUnit4 TemporaryFolder
atau Go TempDir
, memiliki cara sendiri untuk membuat direktori sementara di /tmp
. Framework pengujian
ini menyertakan fungsi yang membersihkan file di /tmp
, sehingga Anda dapat menggunakannya
meskipun 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 tersedia.
Pengujian tidak boleh mengakses output sistem build lain di jalur yang disimpulkan dari lokasi file yang dapat dieksekusinya sendiri.
Tidak ditentukan apakah hierarki runfiles berisi file biasa, link simbolis, atau campuran. Hierarki runfiles dapat berisi symlink ke direktori.
Pengujian harus menghindari penggunaan jalur yang berisi komponen ..
dalam hierarki
runfiles.
Tidak ada direktori, file, atau symlink dalam hierarki runfiles (termasuk jalur yang
melintasi symlink) yang harus dapat ditulis. (Karenanya direktori kerja
awal tidak boleh ditulis.) Pengujian tidak boleh berasumsi bahwa ada bagian dari runfile yang dapat ditulis, atau dimiliki oleh pengguna saat ini (misalnya, chmod
dan chgrp
mungkin akan gagal).
Hierarki runfiles (termasuk jalur yang melintasi symlink) tidak boleh berubah selama eksekusi pengujian. Direktori induk dan pemasangan sistem file tidak boleh berubah dengan cara apa pun, yang memengaruhi hasil penyelesaian jalur dalam hierarki runfile.
Untuk melihat proses keluar lebih awal, pengujian dapat membuat file di jalur yang ditentukan oleh
TEST_PREMATURE_EXIT_FILE
saat memulai dan menghapusnya saat keluar. Jika melihat
file saat pengujian selesai, Bazel akan menganggap pengujian keluar sebelum waktunya dan
menandainya sebagai gagal.
Konvensi tag
Beberapa tag dalam aturan pengujian memiliki arti khusus. Lihat juga
Bazel Build Encyclopedia tentang atribut tags
.
Tag | Arti |
---|---|
exclusive |
tidak boleh menjalankan pengujian lain secara bersamaan |
external |
test memiliki dependensi eksternal; nonaktifkan pengujian cache |
large |
Konvensi test_suite ; rangkaian pengujian besar |
manual * |
tidak menyertakan target pengujian dalam pola target karakter pengganti seperti
:... , :* , atau :all |
medium |
Konvensi test_suite ; rangkaian pengujian sedang |
small |
Konvensi test_suite ; rangkaian pengujian kecil |
smoke |
test_suite ; berarti aplikasi harus dijalankan sebelum
melakukan perubahan kode ke dalam sistem kontrol versi |
{i>Runfile<i}
Dalam contoh berikut, asumsikan ada aturan *_binary() berlabel
//foo/bar:unittest
, dengan dependensi run-time 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
aturan *_binary()
. Direktori runfiles itu sendiri bergantung pada kumpulan file BUILD
yang memengaruhi aturan *_binary()
atau dependensi waktu kompilasinya
atau waktu run-nya. Memodifikasi file sumber tidak memengaruhi struktur direktori runfiles, dan dengan demikian tidak memicu pembangunan ulang apa pun.
Daftar Isi
Direktori runfiles berisi hal-hal berikut:
- Symlink ke dependensi run-time: setiap OutputFile dan CommandRule yang
merupakan dependensi run-time aturan
*_binary()
direpresentasikan oleh satu symlink di direktori runfiles. Nama symlink ini adalah$(WORKSPACE)/package_name/rule_name
. Misalnya, symlink untuk server akan diberi nama$(WORKSPACE)/deps/server/server
, dan jalur lengkapnya adalah$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server
. Tujuan symlink adalah OutputFileName() dari OutputFile atau CommandRule, yang dinyatakan sebagai jalur absolut. Dengan demikian, tujuan symlink mungkin$(WORKSPACE)/linux-dbg/deps/server/42/server
. - Symlink ke sub-runfile: untuk setiap
*_binary()
Z yang merupakan dependensi run-time*_binary()
C, ada link kedua dalam direktori runfile C ke runfile Z. Nama symlink ini adalah$(WORKSPACE)/package_name/rule_name.runfiles
. Target symlink adalah direktori runfiles. Misalnya, semua subprogram memiliki direktori runfile yang sama.