Spesifikasi lengkap lingkungan eksekusi pengujian.
Latar belakang
Bahasa BUILD Bazel 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, karena pemanggilan tersebut tidak akan mematuhi perintah yang dijelaskan di bawah.
Pengujian harus hermetis: artinya, pengujian hanya boleh mengakses resource yang memiliki dependensi yang dideklarasikan. Jika pengujian tidak sepenuhnya tertutup, pengujian tersebut tidak akan memberikan hasil yang dapat direproduksi secara historis. Hal ini dapat menjadi masalah signifikan untuk menemukan penyebab (menentukan perubahan mana yang menyebabkan pengujian gagal), auditabilitas rekayasa rilis, dan isolasi resource pengujian (framework pengujian otomatis tidak boleh melakukan serangan DDoS pada server karena beberapa pengujian kebetulan berinteraksi dengan server tersebut).
Tujuan
Tujuan halaman ini adalah untuk menetapkan secara formal lingkungan runtime dan perilaku yang diharapkan dari pengujian Bazel. Hal ini juga akan memaksakan 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 kepada infrastruktur pengujian untuk melakukan perubahan implementasi. Spesifikasi ini memperketat beberapa celah yang saat ini memungkinkan banyak pengujian lulus meskipun tidak hermetik, deterministik, dan dapat dimasuki kembali dengan benar.
Halaman ini dimaksudkan untuk menjadi normatif dan berwibawa. Jika spesifikasi ini dan perilaku runner pengujian yang diterapkan tidak sesuai, spesifikasi akan diutamakan.
Spesifikasi yang Diusulkan
Kata kunci "HARUS", "TIDAK BOLEH", "WAJIB", "HARUS", "TIDAK BOLEH", "SEBAIKNYA", "SEBAIKNYA TIDAK", "DISARANKAN", "MUNGKIN", dan "OPSIONAL" harus ditafsirkan seperti yang dijelaskan dalam IETF RFC 2119.
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 standar, dan hal lain yang disimpan di bawah kontrol versi.) Seorang pengguna menulis tes untuk menegaskan invarian yang diharapkan dipertahankan. Pengguna lain menjalankan pengujian nanti untuk memeriksa apakah invarian telah dilanggar. Jika pengujian bergantung pada variabel selain file sumber (non-hermetik), nilainya akan berkurang, karena pengguna selanjutnya tidak dapat memastikan apakah perubahan mereka yang menyebabkan pengujian berhenti berhasil.
Oleh karena itu, hasil pengujian hanya boleh bergantung pada:
- file sumber yang menjadi dependensi yang dideklarasikan oleh pengujian
- produk sistem build yang menjadi dependensi yang dideklarasikan oleh pengujian
- resource yang perilakunya dijamin oleh pelaksana pengujian akan tetap konstan
Saat ini, perilaku tersebut tidak diterapkan. Namun, pelaksana pengujian berhak menambahkan pemberlakuan tersebut pada masa mendatang.
Peran sistem build
Aturan pengujian analog dengan aturan biner karena setiap aturan harus menghasilkan program yang dapat dieksekusi. Untuk beberapa bahasa, ini adalah program stub yang menggabungkan harness khusus bahasa dengan kode pengujian. Aturan pengujian juga harus menghasilkan output lain. Selain executable pengujian utama, peluncur 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 file yang dapat dijalankan untuk mengirimkan kode dan data. (Hal ini dapat digunakan sebagai pengoptimalan untuk membuat setiap biner pengujian lebih kecil dengan membagikan file di seluruh pengujian, seperti melalui penggunaan deep link.) Sistem build harus memastikan bahwa file yang dapat dieksekusi yang dihasilkan memuat file ini melalui image runfile yang disediakan oleh peluncur pengujian, bukan referensi hardcode ke lokasi absolut dalam hierarki sumber atau output.
Peran pelaksana pengujian
Dari sudut pandang test runner, setiap pengujian adalah program yang dapat dipanggil dengan execve(). Mungkin ada cara lain untuk menjalankan pengujian; misalnya,
IDE mungkin memungkinkan eksekusi pengujian Java dalam proses. Namun, hasil
menjalankan pengujian sebagai proses mandiri harus dianggap sebagai yang paling akurat. Jika
proses pengujian berjalan hingga selesai dan berakhir secara normal dengan kode keluar
nol, pengujian telah lulus. Hasil lainnya dianggap sebagai kegagalan pengujian. Khususnya, menulis string PASS atau FAIL ke stdout tidak memiliki arti apa pun bagi pelaksana pengujian.
Jika pengujian memerlukan waktu terlalu lama untuk dieksekusi, melampaui batas resource tertentu, atau pelaksana pengujian mendeteksi perilaku yang dilarang, pelaksana pengujian dapat memilih untuk menghentikan pengujian dan memperlakukan eksekusi sebagai kegagalan. Runner tidak boleh melaporkan pengujian sebagai lulus setelah mengirim sinyal ke proses pengujian atau turunannya.
Seluruh target pengujian (bukan metode atau pengujian individual) diberi waktu terbatas untuk berjalan hingga selesai. Batas waktu untuk pengujian didasarkan pada atribut
timeout sesuai dengan tabel berikut:
| timeout | Batas Waktu (detik) |
|---|---|
| short | 60 |
| sedang | 300 |
| long | 900 |
| abadi | 3600 |
Pengujian yang tidak secara eksplisit menentukan waktu tunggu memiliki satu waktu tunggu implisit berdasarkan
size pengujian sebagai berikut:
| ukuran | Label waktu tunggu tersirat |
|---|---|
| kecil | short |
| sedang | sedang |
| besar | long |
| sangat besar | abadi |
Pengujian "besar" tanpa setelan waktu tunggu eksplisit akan dialokasikan 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 sah, sehingga pengujian "sangat besar" dapat dinyatakan memiliki waktu tunggu "pendek". Mungkin ia akan melakukan hal-hal yang sangat buruk dengan sangat cepat.
Pengujian dapat ditampilkan dengan sangat cepat, terlepas dari waktu tunggu. Pengujian tidak dikenai penalti karena waktu tunggu yang terlalu besar, meskipun peringatan dapat diberikan: Anda sebaiknya menetapkan waktu tunggu seketat mungkin tanpa menimbulkan ketidakstabilan.
Waktu tunggu pengujian dapat diganti dengan tanda bazel --test_timeout saat menjalankan 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 sebagai 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 ukurannya terlalu besar.
Ukuran dan waktu tunggu pengujian ditentukan dalam file BUILD sesuai dengan spesifikasi di sini. Jika tidak ditentukan, ukuran pengujian akan ditetapkan ke "medium" secara default.
Jika proses utama pengujian keluar, tetapi beberapa turunannya masih berjalan, pelaksana pengujian harus menganggap bahwa pengujian telah selesai dan menghitungnya sebagai keberhasilan atau kegagalan berdasarkan kode keluar yang diamati dari proses utama. Runner pengujian dapat menghentikan proses yang tidak diperlukan. Pengujian tidak boleh membocorkan proses dengan cara ini.
Pengujian sharding
Pengujian dapat diparalelkan melalui sharding pengujian. Lihat
--test_sharding_strategy
dan shard_count untuk
mengaktifkan sharding pengujian. Jika sharding diaktifkan, runner pengujian diluncurkan satu kali per shard. Variabel lingkungan TEST_TOTAL_SHARDS
adalah jumlah shard, dan TEST_SHARD_INDEX adalah
indeks shard, dimulai dari 0. Runner menggunakan informasi ini untuk memilih pengujian mana yang akan dijalankan, misalnya, menggunakan strategi round-robin. Tidak semua pelari 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-shard.
Kondisi awal
Saat menjalankan pengujian, pelaksana pengujian harus menetapkan kondisi awal tertentu.
Runner pengujian harus memanggil setiap pengujian dengan jalur ke file yang dapat dieksekusi dalam
argv[0]. Jalur ini harus relatif dan berada di bawah direktori saat ini pengujian
(yang ada di hierarki file yang dijalankan, lihat di bawah). Pelaksana 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 |
unset | wajib diisi |
LANGUAGE |
unset | wajib diisi |
LC_ALL |
unset | wajib diisi |
LC_COLLATE |
unset | wajib diisi |
LC_CTYPE |
unset | wajib diisi |
LC_MESSAGES |
unset | wajib diisi |
LC_MONETARY |
unset | wajib diisi |
LC_NUMERIC |
unset | wajib diisi |
LC_TIME |
unset | wajib diisi |
LD_LIBRARY_PATH |
daftar direktori yang berisi library bersama yang dipisahkan dengan titik dua | 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 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 khusus untuk pengujian, tetapi dapat menyebabkan kegagalan pengujian karena tidak berfungsi dengan baik. 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 di direktori yang dapat ditulis (digunakan untuk menulis log protobuffer Logsplitter) | opsional |
TEST_PREMATURE_EXIT_FILE |
jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk
mencatat 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 eksekusi pengujian. |
opsional |
TEST_RUN_NUMBER |
Jika opsi --runs_per_test digunakan,
TEST_RUN_NUMBER disetel ke run number
(dimulai dengan 1) untuk setiap eksekusi pengujian. |
opsional |
TEST_TARGET |
Nama target yang sedang diuji | opsional |
TEST_SIZE |
Pengujian size |
opsional |
TEST_TIMEOUT |
Pengujian timeout dalam detik |
opsional |
TEST_SHARD_INDEX |
indeks shard, jika sharding digunakan |
opsional |
TEST_SHARD_STATUS_FILE |
jalur ke file yang akan disentuh untuk menunjukkan dukungan terhadap sharding |
opsional |
TEST_SRCDIR |
jalur absolut ke dasar hierarki runfile | 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 yang dapat ditulis pribadi (digunakan untuk menulis output pengujian yang tidak dideklarasikan). Semua file yang ditulis ke
direktori TEST_UNDECLARED_OUTPUTS_DIR akan di-zip dan
ditambahkan ke file outputs.zip di bawah
bazel-testlogs. |
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 di 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 membuat file output XML default yang membungkus log pengujian sebagai bagian dari tindakan pengujian. Skema XML didasarkan pada skema hasil pengujian JUnit. | opsional |
BAZEL_TEST |
Menandakan bahwa executable pengujian sedang dijalankan oleh bazel test |
wajib diisi |
Lingkungan dapat berisi entri tambahan. Pengujian tidak boleh bergantung pada keberadaan, ketiadaan, atau nilai variabel lingkungan 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. Proses ini mungkin atau mungkin tidak menjadi pemimpin grup proses atau pemimpin sesi. Proses mungkin memiliki atau tidak memiliki terminal kontrol. Proses ini mungkin memiliki nol atau lebih banyak proses turunan yang sedang berjalan atau belum dipanen. Proses tidak boleh memiliki beberapa thread saat kode pengujian mendapatkan kontrol.
Deskriptor file 0 (stdin) harus dibuka untuk dibaca, tetapi apa yang dilampirkan
tidak ditentukan. Pengujian tidak boleh membacanya. Deskriptor file 1 (stdout) dan 2
(stderr) harus terbuka untuk penulisan, tetapi apa yang dilampirkan tidak
ditentukan. Objek ini bisa berupa terminal, pipe, file reguler, atau apa pun yang dapat ditulis karakternya. Mereka dapat berbagi entri dalam tabel file terbuka
(yang berarti mereka tidak dapat mencari secara independen). Pengujian tidak boleh mewarisi deskriptor file terbuka lainnya.
umask awal harus 022 atau 027.
Tidak ada alarm atau timer interval yang tertunda.
Masker awal sinyal yang diblokir harus kosong. Semua sinyal akan disetel ke tindakan defaultnya.
Batas resource awal, baik lunak maupun keras, harus ditetapkan 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 |
minimal 1.024 |
RLIMIT_NPROC |
belum ditetapkan |
RLIMIT_RSS |
tak terbatas |
RLIMIT_RTPRIO |
belum ditetapkan |
RLIMIT_SIGPENDING |
belum ditetapkan |
RLIMIT_STACK |
tidak terbatas, atau 2044 KB <= rlim <= 8192 KB |
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 yang berada di bawah kontrol langsung pelaksana pengujian, sistem operasi tempat pengujian dijalankan harus memenuhi properti tertentu agar uji coba valid.
Filesystem
Direktori root yang diamati oleh pengujian mungkin merupakan direktori root yang sebenarnya atau bukan.
/proc harus dipasang.
Semua alat build harus ada di jalur absolut di bagian /usr yang digunakan oleh penginstalan
lokal.
Jalur yang dimulai dengan /home mungkin tidak tersedia. Pengujian tidak boleh mengakses jalur tersebut.
/tmp dapat ditulis, tetapi pengujian harus menghindari penggunaan jalur ini.
Pengujian tidak boleh mengasumsikan bahwa jalur konstan tersedia untuk penggunaan eksklusifnya.
Pengujian tidak boleh mengasumsikan bahwa atime diaktifkan untuk sistem file yang terpasang.
Pengguna dan grup
Pengguna root, nobody, dan unittest harus ada. Root grup, nobody, dan eng harus ada.
Pengujian harus dijalankan sebagai pengguna non-root. ID pengguna efektif dan sebenarnya harus sama; demikian juga untuk ID grup. Selain itu, ID pengguna, ID grup, nama pengguna, dan nama grup saat ini tidak ditentukan. Kumpulan ID grup 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 grup tambahan.
Pengguna saat ini harus memiliki direktori beranda. Direktori mungkin tidak dapat ditulis. Pengujian tidak boleh mencoba menulis ke dalamnya.
Networking
Nama host tidak ditentukan. Mungkin berisi atau tidak berisi titik. Penyelesaian nama host harus memberikan alamat IP host saat ini. Penyelesaian nama host yang dipotong setelah titik pertama juga harus berfungsi. Nama host localhost harus di-resolve.
Referensi lainnya
Pengujian diberi setidaknya satu core CPU. Paket lain 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" (dengan n adalah bilangan positif) ke aturan pengujian. Jika mesin memiliki total core CPU yang lebih sedikit daripada yang diminta, Bazel akan tetap menjalankan pengujian. Jika pengujian menggunakan sharding, setiap shard akan mencadangkan jumlah core CPU yang ditentukan di sini.
Pengujian dapat membuat subproses, tetapi tidak membuat grup proses atau sesi.
Ada batasan jumlah file input yang dapat digunakan oleh pengujian. Batas ini dapat berubah, tetapi saat ini berada dalam kisaran 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 disetel).
Direktori ini awalnya akan kosong.
Pengujian tidak boleh mencoba menghapus, chmod, atau mengubah direktori ini.
Direktori ini mungkin berupa link simbolis.
Jenis sistem file $TEST_TMPDIR/. tetap tidak ditentukan.
Pengujian juga dapat menulis file .part ke
$TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR untuk memberi anotasi pada 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 /tmp. Bazel tidak akan dapat melacak file tersebut; pengujian itu sendiri harus berhati-hati agar bersifat hermetik, menggunakan jalur unik untuk menghindari konflik dengan pengujian lain yang berjalan secara bersamaan dan proses non-pengujian, serta menghapus file yang dibuatnya di /tmp.
Beberapa framework pengujian populer, seperti
JUnit4 TemporaryFolder
atau Go TempDir, memiliki
cara sendiri untuk membuat direktori sementara di /tmp. Framework pengujian ini mencakup 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 menyediakan file input.
Pengujian tidak boleh mengakses output lain dari sistem build di jalur yang disimpulkan dari lokasi file yang dapat dieksekusi miliknya sendiri.
Tidak ditentukan apakah hierarki runfiles berisi file reguler, link
simbolis, atau campuran. Struktur runfile dapat berisi symlink ke direktori.
Pengujian harus menghindari penggunaan jalur yang berisi komponen .. dalam hierarki
runfiles.
Tidak ada direktori, file, atau symlink dalam hierarki runfile (termasuk jalur yang melintasi symlink) yang boleh dapat ditulis. (Dengan demikian, direktori kerja awal tidak boleh dapat ditulis.) Pengujian tidak boleh mengasumsikan bahwa bagian mana pun dari
runfiles dapat ditulis, atau dimiliki oleh pengguna saat ini (misalnya, chmod dan chgrp dapat
gagal).
Struktur runfile (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 menangkap keluar lebih awal, pengujian dapat membuat file di jalur yang ditentukan oleh
TEST_PREMATURE_EXIT_FILE saat dimulai dan menghapusnya saat keluar. Jika Bazel melihat
file saat pengujian selesai, Bazel akan menganggap bahwa pengujian keluar sebelum waktunya dan
menandainya sebagai gagal.
Konvensi tag
Beberapa tag dalam aturan pengujian memiliki arti khusus. Lihat juga
Ensiklopedia Build Bazel tentang atribut tags.
| Tag | Arti |
|---|---|
exclusive |
tidak menjalankan pengujian lain secara bersamaan |
external |
pengujian memiliki dependensi eksternal; nonaktifkan penayangan cache pengujian |
large |
test_suite konvensi; rangkaian 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; rangkaian pengujian kecil |
smoke |
test_suite konvensi; berarti harus dijalankan sebelum
melakukan perubahan kode ke dalam sistem kontrol versi |
Runfiles
Di bawah ini, asumsikan ada aturan *_binary() berlabel
//foo/bar:unittest, dengan dependensi waktu proses pada aturan berlabel
//deps/server:server.
Lokasi
Direktori runfile untuk target //foo/bar:unittest 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 kompilasi atau waktu prosesnya. Memodifikasi file sumber tidak memengaruhi struktur direktori runfiles, sehingga tidak memicu pembangunan ulang.
Daftar Isi
Direktori runfiles berisi hal berikut:
- Link simbolis ke dependensi waktu proses: setiap OutputFile dan CommandRule yang
merupakan dependensi waktu proses aturan
*_binary()diwakili oleh satu link simbolis di direktori runfiles. Nama symlink 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 berupa$(WORKSPACE)/linux-dbg/deps/server/42/server. - Symlink ke sub-runfile: untuk setiap
*_binary()Z yang merupakan dependensi waktu proses*_binary()C, ada link kedua di direktori runfile C ke runfile Z. Nama symlink adalah$(WORKSPACE)/package_name/rule_name.runfiles. Target symlink adalah direktori runfile. Misalnya, semua subprogram berbagi direktori file yang dapat dijalankan yang sama.