Test yürütme ortamı için kapsamlı bir spesifikasyon.
Arka plan
Bazel BUILD dili, otomatik tanımlamaları tanımlamak için kullanılabilecek kurallar içerir. pek çok dildeki test programlarına erişebilirsiniz.
Testler bazel test kullanılarak çalıştırılır.
Kullanıcılar ayrıca test ikili programlarını doğrudan yürütebilir. Bu izin verilir ancak desteklenmez, bu nedenle de bir çağrı aşağıda açıklanan zorunluluklara uygun olmayacaktır.
Testler hermetik olmalıdır. Yani yalnızca bu kaynaklara erişebilmelidir. açıklanmış bir bağımlılığı bulunuyor. Testler düzgün bir şekilde hermetik değilse bu durumda da geçmişe dönük tekrarlanabilir sonuçlar sağlamaz. Bu, bir suçlu bulma açısından önemli bir sorun (hangi değişikliğin testi bozduğunu belirleme), testlerin kaynak izolasyonu (otomatik bazı testler sunucularla iletişim kurduğundan, test çerçeveleri DDoS'a .
Hedef
Bu sayfanın amacı, Virtual Verde için çalışma zamanı ortamını ve Bazel testlerinin beklenen davranışını gösterebilir. Ayrıca teste bazı şartlar da çalışan biri.
Test ortamı spesifikasyonu, test yazarlarının belirsiz şekilde çalışır ve böylece test altyapısına, üzerinde ve uygulama değişiklikleri yapabilirsiniz. Bu spesifikasyon, tablodaki hermetik olmasa da çoğu testin başarılı olmasına izin verir. belirleyici ve geri gelen kişidir.
Bu sayfanın hem normatif hem de güvenilir olması amaçlanmıştır. Bu test çalıştırıcısının özellikleri ve uygulanan davranışı öncelikli hale getirir.
Önerilen Spesifikasyon
Şu anahtar kelimeler "ZORUNLU", "ZORUNLU OLMAMALIDIR", "GEREKLİ", "YAPILMAYACAK", "YA ALINMAMALIDIR", "KULLANMAMALIDIR", "ÖNERİLİR", "MAYIS" ve "İSTEĞE BAĞLI" şu şekilde yorumlanmalıdır: RFC 2119'da açıklanmıştır.
Testlerin amacı
Bazel testlerinin amacı, kaynak dosyaların bazı özelliklerini onaylamaktır giriş yapıldı. (Bu sayfada, "kaynak dosyalar" test verilerini içerir, altın çıktılar ve sürüm kontrolü altında tutulan her şey.) Bir kullanıcı, korunmasını bekledikleri bir sabit değer test etmek zorundadır. Diğer kullanıcılar sabit öğenin bozuk olup olmadığını kontrol etmek için daha sonra testi yürütün. Öğe test, kaynak dosyalar (hermetik olmayan) dışındaki değişkenlere bağlıdır, sonraki kullanıcılar değişikliklerinin hatalı olduğundan emin olamayacağından reklam öğesi sayısı azalır testin geçilmesi durduğunda önemlidir.
Bu nedenle, testin sonucu yalnızca aşağıdakilere bağlı olmalıdır:
- testin bildirilen bağımlılığı olduğu kaynak dosyalar
- testin bildirilen bağımlılığı olduğu derleme sistemindeki ürünler
- davranışı test çalıştırıcı tarafından sabit kalması garanti edilen kaynaklar
Şu anda bu tür bir davranış zorunlu kılınmamaktadır. Ancak test katılımcıları bu tür bir yaptırım ekleme hakkına sahip olduğunuzu unutmayın.
Derleme sisteminin rolü
Test kuralları ikili kurallara benzer, çünkü her birinin çalıştırılabilir bir sonuç vermesi gerekir çok önemli. Bazı dillerde, bu bir temel program olan test koduyla dile özgü değişiklikler yapılabilir. Test kuralları, çıktıları için de geçerlidir. Yürütülebilir birincil teste ek olarak, test çalıştırıcısı da runfiles'in bir manifest'i (kullanılabilir olması gereken giriş dosyaları) gerekir yapabilir ve türü, boyutu ve boyutu ile ilgili bilgilere etiketidir.
Derleme sistemi, çalıştırma dosyalarını ve verilerin yanı sıra kodu da yayınlamak için kullanabilir. (Bu için bir optimizasyon olarak kullanılabilir ve böylece her test ikili programının dosyalarını test edebilir ve ekleyebilirsiniz.) Derleme sistemi oluşturulan yürütülebilir dosyanın, bu dosyaları çalıştırma dosyaları aracılığıyla yüklediğinden emin olmalıdır. sabit kodlu referanslar yerine test çalıştırıcısı tarafından sağlanan resim konumlarını kaynak veya çıkış ağacında bulabilirsiniz.
Test çalıştırıcının rolü
Test çalıştırıcısı açısından her test, farklı alanlarda
execve() ile çağrıldı. Testleri yürütmenin başka yolları da olabilir. örneğin,
IDE, işlemdeki Java testlerinin yürütülmesine izin verebilir. Ancak sonuç
testinin bağımsız bir süreç olarak çalıştırılmasının güvenilir kabul edilmesi gerekir. Eğer
bir test işlemi tamamlanana kadar çalışır ve şu çıkış koduyla normal bir şekilde sona erer:
test geçilmiş demektir. Diğer tüm sonuçlar test hatası olarak kabul edilir. İçinde
PASS veya FAIL dizelerinden herhangi birinin stdout'a yazılması,
için ne kadar önemli
olduğunu konuşalım.
Bir testin yürütülmesi çok uzun sürerse, kaynak sınırının bir kısmını aşarsa veya test Aksi takdirde, izin verilmeyen davranışları tespit ettiğinde testi sonlandırmayı ve olarak değerlendirebilir. Koşucu, testin başarılı sonuç verdiğini bildirmemelidir. test sürecine veya test sürecine bir sinyal gönderme.
Test hedefinin tamamına (tek tek yöntemler veya testler değil) sınırlı bir süre verilir.
süre tahmini de olabilir. Bir test için zaman sınırı
timeout özelliğini
şu tabloya ekleyin:
| Mola | Zaman Sınırı (sn.) |
|---|---|
| kısa video | 60 |
| orta | 300 |
| uzun | 900 |
| sonsuz | 3600 |
Açıkça bir zaman aşımı belirtmeyen testler,
testin size değerini aşağıda görebilirsiniz:
| beden | Dolaylı zaman aşımı etiketi |
|---|---|
| küçük | kısa video |
| medium | orta |
| büyük | uzun |
| devasa | sonsuz |
"Büyük" açıkça zaman aşımı ayarı olmadan test için 900 atanır saniye olarak kullanılabilir. Bir "aracı" "short" zaman aşımıyla test et 60 olarak atanacak saniye.
timeout verilerinin aksine size, ayrıca
aşağıdaki adımları uygulayarak testi yerel olarak çalıştırırken diğer kaynaklar (RAM gibi)
Yaygın tanımlar.
Tüm size ve timeout etiketi kombinasyonları yasaldır, bu nedenle "çok büyük" deneme
zaman aşımının "kısa" olduğu açıklanabilir. Büyük olasılıkla bu sayede
korkunç şeylerle uğraşıyorduk.
Testler, zaman aşımından bağımsız olarak rastgele hızlı bir şekilde döndürülebilir. Teste ceza verilmez aşırı uzun bir zaman aşımı yaşar, ancak bir uyarı yapılabilir: genellikle zaman aşımını herhangi bir sorun yaşamadan olabildiğince kısa tutun.
Aşağıdaki durumlarda test zaman aşımı --test_timeout bazel işareti ile geçersiz kılınabilir
Yavaş olduğu bilinen koşullarda manuel olarak çalıştırılabilir. İlgili içeriği oluşturmak için kullanılan
--test_timeout değerleri saniye cinsindendir. Örneğin, --test_timeout=120
test zaman aşımını iki dakikaya ayarlar.
Ayrıca test zaman aşımları için aşağıdaki gibi bir alt sınır da önerilir:
| Mola | Minimum süre (sn.) |
|---|---|
| kısa video | 0 |
| orta | 30 |
| uzun | 300 |
| sonsuz | 900 |
Örneğin, "orta düzey" test 5, 5 sn.içinde tamamlanırsa timeout =
"short" veya size = "small" ayarlamayı düşünün. --test_verbose_timeout_warnings temelini kullanma
komut satırı seçeneği, belirtilen boyutu çok büyük olan testleri gösterir.
Test boyutları ve zaman aşımları BUILD dosyasında burada bulabilirsiniz. Eğer bir değer belirtilmezse testin boyutu varsayılan olarak "orta" olur.
Bir testin ana işlemi çıksa da bazı alt öğeleri hâlâ çalışıyorsa test koşucusu koşuyu tamamlanmış kabul etmeli ve bunu başarılı ya da hatasına neden olur. Test koşucusu bilmeyen süreçleri yok edebilir. Testler, süreçleri bu şekilde sızdırmamalıdır.
Test kırma
Testler, test parçalama yöntemiyle paralel hale getirilebilir. Görüntüleyin
--test_sharding_strategy
ve shard_count ile
test parçalamayı etkinleştir. Parçalama etkinleştirildiğinde test çalıştırıcı bir kez başlatılır
bir öğedir. TEST_TOTAL_SHARDS ortam değişkeni
ise kırık sayısıdır, TEST_SHARD_INDEX ise
0'dan başlayan kırık dizini. Çalıştırıcılar bu bilgileri kullanarak hangi testleri
çok önemlidir. Tüm test koşucuları desteklemez
söz konusu olabilir. Parçalamayı destekleyen bir koşucu, son parçayı oluşturmalı veya
dosyanın değişiklik tarihini
TEST_SHARD_STATUS_FILE. Aksi halde
--incompatible_check_sharding_support
etkinleştirilirse Bazel parçalanırsa testte başarısız olur.
Başlangıç koşulları
Bir test yürütürken, test çalıştırıcının başlangıçtaki hedeflerini belirlemesi koşullar.
Test çalıştırıcısı, çalıştırılabilir test dosyasının yolunu içeren her bir testi
argv[0] Bu yol göreli ve testin geçerli dizininin altında olmalıdır
(runfiles ağacında, aşağıya bakın). Test koşucusu, testin
kullanıcı açık bir şekilde istekte bulunmadığı sürece test için diğer bağımsız değişkenlerden yararlanamaz.
İlk ortam bloğu aşağıdaki gibi oluşacaktır:
| Değişken | Değer | Durum |
|---|---|---|
HOME |
$TEST_TMPDIR değeri |
önerilen |
LANG |
ayarlanmadı | zorunlu |
LANGUAGE |
ayarlanmadı | zorunlu |
LC_ALL |
ayarlanmadı | zorunlu |
LC_COLLATE |
ayarlanmadı | zorunlu |
LC_CTYPE |
ayarlanmadı | zorunlu |
LC_MESSAGES |
ayarlanmadı | zorunlu |
LC_MONETARY |
ayarlanmadı | zorunlu |
LC_NUMERIC |
ayarlanmadı | zorunlu |
LC_TIME |
ayarlanmadı | zorunlu |
LD_LIBRARY_PATH |
paylaşılan kitaplıkları içeren dizinlerin iki nokta üst üste ile ayrılmış listesi | isteğe bağlı |
JAVA_RUNFILES |
$TEST_SRCDIR değeri |
desteği sonlandırıldı |
LOGNAME |
$USER değeri |
zorunlu |
PATH |
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. |
önerilen |
PWD |
$TEST_SRCDIR/workspace-name |
önerilen |
SHLVL |
2 |
önerilen |
TEST_INFRASTRUCTURE_FAILURE_FILE |
yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (Bu dosya Yalnızca testten kaynaklanan hataları bildirmek için kullanılmalıdır altyapı sunmaz, stabil olmayan arızaları bildirmek için genel bir mekanizma olarak değil, olabilir. Bu bağlamda test altyapısı, sistem olarak veya kitaplıklar arasında teste özgü olmayan, ancak test hatasına neden olan işlevi görmeyecektir. İlk satır, test altyapısının adıdır. bileşen, ikincisi ise kullanıcılar tarafından okunabilen hatanın açıklaması. Ek satırlar yoksayılır.) | isteğe bağlı |
TEST_LOGSPLITTER_OUTPUT_FILE |
yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (yazmak için kullanılır Günlük kesici proto arabellek günlüğü) | isteğe bağlı |
TEST_PREMATURE_EXIT_FILE |
yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (
exit() için yapılan aramalar alınıyor) |
isteğe bağlı |
TEST_RANDOM_SEED |
--runs_per_test seçeneği kullanılırsa
TEST_RANDOM_SEED, run number olarak ayarlandı
(1 ile başlayan) belirten bir değer alır. |
isteğe bağlı |
TEST_RUN_NUMBER |
--runs_per_test seçeneği kullanılırsa
TEST_RUN_NUMBER, run number olarak ayarlandı
(1 ile başlayan) belirten bir değer alır. |
isteğe bağlı |
TEST_TARGET |
Test edilen hedefin adı | isteğe bağlı |
TEST_SIZE |
size testi |
isteğe bağlı |
TEST_TIMEOUT |
Saniyeler içinde timeout testi |
isteğe bağlı |
TEST_SHARD_INDEX |
sharding kullanılıyorsa kırık dizini |
isteğe bağlı |
TEST_SHARD_STATUS_FILE |
sharding desteği olduğunu belirtmek için dokunulacak dosyanın yolu |
isteğe bağlı |
TEST_SRCDIR |
çalıştırma dosyaları ağacının tabanının mutlak yolu | zorunlu |
TEST_TOTAL_SHARDS |
toplam
shard count
sharding kullanılıyorsa |
isteğe bağlı |
TEST_TMPDIR |
özel yazılabilir bir dizine giden mutlak yol | zorunlu |
TEST_WORKSPACE |
yerel deponun çalışma alanı adı | isteğe bağlı |
TEST_UNDECLARED_OUTPUTS_DIR |
özel yazılabilir bir dizine giden mutlak yol (bildirilmeyen bir dizin yazmak için kullanılır
test çıkışları arasında).
TEST_UNDECLARED_OUTPUTS_DIR dizin sıkıştırılacak ve
şunun altındaki bir outputs.zip dosyasına eklendi:
bazel-testlogs. |
isteğe bağlı |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR |
özel yazılabilir bir dizine giden mutlak yol (bildirilmeyen bir dizin yazmak için kullanılır
test çıkış ek açıklaması .part ve .pb dosyaları) ekleyin. |
isteğe bağlı |
TEST_WARNINGS_OUTPUT_FILE |
yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (yazmak için kullanılır test hedefi uyarılarını test edin) | isteğe bağlı |
TESTBRIDGE_TEST_ONLY |
değeri
--test_filter
belirtilirse |
isteğe bağlı |
TZ |
UTC |
zorunlu |
USER |
getpwuid(getuid())->pw_name değeri |
zorunlu |
XML_OUTPUT_FILE |
Test işlemlerinin bir test sonucu XML çıkış dosyası yazması gereken konum. Aksi takdirde, Bazel test günlüğünü sarmalayan varsayılan bir XML çıkış dosyası oluşturur. test işleminin bir parçası olarak. XML şeması, JUnit test sonucu şeması. | isteğe bağlı |
BAZEL_TEST |
Yürütülebilir test testinin bazel test tarafından desteklendiğini gösterir |
zorunlu |
Ortamda ek girişler olabilir. Testler yukarıda listelenmeyen herhangi bir ortam değişkeninin varlığı, yokluğu veya değeri.
İlk çalışma dizini $TEST_SRCDIR/$TEST_WORKSPACE olmalıdır.
Geçerli işlem kimliği, işlem grubu kimliği, oturum kimliği ve üst işlem kimliği: belirtilmemiş. Süreç, bir süreç grubu lideri veya oturum olabilir ya da olmayabilir. liderlik eder. Süreçte kontrol terminali olabilir veya olmayabilir. Süreç, ya da daha fazla devam eden veya tamamlanmamış alt işleme sahip olmalıdır. Süreç boyunca test kodu kontrolü ele geçirdiğinde birden fazla iş parçacığı bulunabilir.
Dosya tanımlayıcı 0 (stdin) okunmak için açık olacak, ancak neye ekli olduğu
belirtilmemiş. Testler buradan okunmamalıdır. Dosya açıklayıcıları 1 (stdout) ve 2
(stderr) yazıya açık olacak, ancak ilettiği dosya
belirtilmemiş. Bu bir terminal, ardışık düzen, normal bir dosya veya
hangi karakterin yazılabileceğini belirleyin. Açık dosya tablosunda bir girişi paylaşabilirler
(yani bağımsız olarak arama yapamazlar). Testler,
açık dosya tanımlayıcılarını kullanın.
İlk umask 022 veya 027 olmalıdır.
Bekleyen alarm veya aralıklı zamanlayıcı olmamalıdır.
Engellenen sinyallerin ilk maskesi boş olacaktır. Tüm sinyaller varsayılan işlemi vardır.
Hem düşük hem de zor başlangıçtaki kaynak sınırları aşağıdaki gibi ayarlanmalıdır:
| Kaynak | Sınır |
|---|---|
RLIMIT_AS |
sınırsız |
RLIMIT_CORE |
belirtilmedi |
RLIMIT_CPU |
sınırsız |
RLIMIT_DATA |
sınırsız |
RLIMIT_FSIZE |
sınırsız |
RLIMIT_LOCKS |
sınırsız |
RLIMIT_MEMLOCK |
sınırsız |
RLIMIT_MSGQUEUE |
belirtilmedi |
RLIMIT_NICE |
belirtilmedi |
RLIMIT_NOFILE |
en az 1024 |
RLIMIT_NPROC |
belirtilmedi |
RLIMIT_RSS |
sınırsız |
RLIMIT_RTPRIO |
belirtilmedi |
RLIMIT_SIGPENDING |
belirtilmedi |
RLIMIT_STACK |
sınırsız veya 2044 KB <= rlim <= 8192 KB |
İlk işlem süreleri (times() tarafından döndürülen şekilde) ve kaynak kullanımı
(getrusage() tarafından döndürüldüğü şekliyle) belirtilmemiş.
İlk planlama politikası ve önceliği belirtilmemiş.
Ana makine sisteminin rolü
Testin doğrudan kontrolü altındaki kullanıcı bağlamına ek olarak, testlerin yürütüleceği işletim sisteminin belirli şartları karşılaması gerekir. özelliklerinin geçerli olmasını sağlayın.
Dosya sistemi
Bir test tarafından gözlemlenen kök dizin, gerçek kök dizin olabilir veya olmayabilir.
/proc eklenecek.
Tüm derleme araçları,/usr
yerel kurulum.
/home ile başlayan yollar kullanılamayabilir. Testler,
yolları aranır.
/tmp yazılabilir olmalıdır ancak testlerde bu yolların kullanılmaması gerekir.
Testler, özel URL'ler için sabit bir yolun mevcut olduğunu varsaymamalıdır. pek de iyi olmadığını unutmayın.
Testler, eklenen herhangi bir dosya sistemi için "atimes" özelliğinin etkinleştirildiğini varsaymamalıdır.
Kullanıcılar ve gruplar
Kullanıcı kökü, hiç kimse ve birimtest bulunmalıdır. Grupların kökü, hiç kimse ve eng olmalıdır.
Testler, kök olmayan kullanıcı olarak yürütülmelidir. Gerçek ve etkili kullanıcı kimlikleri, eşit olmalıdır; aynı şekilde grup kimlikleri ekleyebilirsiniz. Bunun dışında, geçerli kullanıcı kimliği, grup kimliği kullanıcı adı ve grup adı belirtilmemiş. Ek grup kimlikleri kümesi: belirtilmemiş.
Geçerli kullanıcı kimliği ve grup kimliğinin karşılık gelen adları olmalıdır.
getpwuid() ve getgrgid() ile alındı. Aynı durum,
proje yöneticiliği
eklemektir.
Geçerli kullanıcının bir ana dizini olmalıdır. Yazılabilir olmayabilir. Testler bir mesaj yazın.
Ağ İletişimi
Ana makine adı belirtilmedi. Nokta içerebilir veya içermeyebilir. Sorunu çözmek ana makine adı, geçerli ana makinenin IP adresini vermelidir. Ana makine adı kesme sorununu çözme sonra gelen kodu da kullanabilirsiniz. Yerel ana makine adı çözümlenmelidir.
Diğer kaynaklar
Testlere en az bir CPU çekirdeği verilir. Başkaları kullanılabilir ancak bu kullanılamaz garantili. Bu çekirdeğin diğer performans yönleri belirtilmemiştir. Şunları yapabilirsiniz: etiketi ekleyerek rezervasyonu daha yüksek sayıda CPU çekirdeğine "cpu:n" (burada n pozitif sayıdır) test kuralına uygulayın. Bir makinede CPU çekirdeği toplamı talep edilenden daha fazlaysa Bazel, testi çalıştırmaya devam eder. Bir test kırma işleminden sonra her bir parça için ayrı CPU sayısı ayrılır. temel değerlerdir.
Testler alt işlemler oluşturabilir ancak işlem grupları veya oturumlar oluşturamaz.
Bir testin kullanabileceği giriş dosyası sayısı sınırlıdır. Bu sınır kullanılabilir ancak şu anda on binlerce giriş aralığındadır.
Saat ve tarih
Geçerli saat ve tarih belirtilmemiş. Sistem saat dilimi belirtilmedi.
X Windows kullanılabilir veya kullanılamayabilir. X sunucusu gerektiren testler başlatılmalıdır Xvfb.
Dosya sistemiyle etkileşimi test edin
Test ortamı değişkenlerinde belirtilen tüm dosya yolları yerel dosya sisteminde (aksi belirtilmedikçe) kullanılabilir.
Testler yalnızca
$TEST_TMPDIR ve $TEST_UNDECLARED_OUTPUTS_DIR (etkinse).
Bu dizinler başlangıçta boş olacaktır.
Testler bu dizinleri kaldırmayı, chmod'u veya başka bir şekilde değiştirmeyi denememelidir.
Bu dizinler sembolik bağlantılar olabilir.
$TEST_TMPDIR/. dosya sistemi türü belirtilmedi.
Testler,
Bildirilmemiş çıkış dosyalarına ek açıklama eklemek için $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR.
Nadir durumlarda, bir testle /tmp içinde dosya oluşturulması zorunlu olabilir. Örneğin,
Unix alan yuvaları için yol uzunluğu sınırları
genellikle yuvanın /tmp altında oluşturulması gerekir. Bazel,
bu tür dosyaları izlemek; testin hermetik özellikte olması gerekir.
aynı anda yürütülen testler ve test dışı yöntemler ile çakışmayı önleyen
ve /tmp ürününde oluşturduğu dosyaları temizleyin.
Örneğin, Google'ın GeoX aracıyla
JUnit4 TemporaryFolder
veya TempDir adresine gidin,
/tmp altında geçici bir dizin oluşturmak için kendi yöntemleri kullanılır. Bu testler
çerçeveler, /tmp içindeki dosyaları temizleyen işlevler içerir, bu nedenle
ancak TEST_TMPDIR dışında dosya oluştursalar bile bu URL'lere erişebilirler.
Testler, girişlere runfiles mekanizması veya özel olarak giriş dosyaları oluşturmak üzere tasarlanmış yürütme ortamı kullanılabilir.
Testler, şuradan tahmin edilen yollarda derleme sisteminin diğer çıkışlarına erişmemelidir: konumuna dikkat etmesi gerekir.
Runfiles ağacının normal dosyalar, sembolik dosyalar içerip içermediği
veya bir karışım olabilir. Runfiles ağacı, dizinlere ilişkin sembolik bağlantılar içerebilir.
Testler, çalıştırma dosyalarında .. bileşen içeren yollar kullanmaktan kaçınmalıdır
ağacı.
Çalışma dosyaları ağacında dizin, dosya veya sembolik bağlantı (
sembolik bağlantılar) yazılabilir olmalıdır. (Böylece, ilk çalışma aşamasındaki
dizini yazılabilir olmamalıdır.) Testler, DMAIC ve Yalın Altı Sigma yaklaşımının
çalıştırma dosyaları yazılabilir veya geçerli kullanıcıya ait (örneğin, chmod ve chgrp
başarısız).
Çalışma dosyaları ağacı (simgesel bağlantılardan geçen yollar dahil) değişmemelidir yardımcı olur. Üst dizinler ve dosya sistemi bağlantıları değişmemelidir herhangi bir şekilde, çalıştırma dosyaları içindeki bir yolun çözümlenmesinin sonucunu etkileyecek herhangi bir şekilde ağacı.
Erken çıkışı yakalamak için bir test,
Başlangıçta TEST_PREMATURE_EXIT_FILE, çıkışta kaldırın. Bazel
dosyasını kullanarak test bittiğinde, testin zamanından önce kapatıldığı varsayılır ve
bu mesajı başarısız olarak işaretleyin.
Etiket kuralları
Test kurallarındaki bazı etiketlerin özel bir anlamı vardır. Ayrıca bkz.
tags özelliğinde Bazel Build Ansiklopedisi.
| Etiket | Anlamı |
|---|---|
exclusive |
aynı anda başka test çalıştırma |
external |
testin dış bağımlılığı vardır. test önbelleğe almayı devre dışı bırak |
large |
test_suite kuralı; kapsamlı testler |
manual * |
gibi joker karakter hedef kalıplarına test hedefini dahil etmeyin:
:..., :* veya :all |
medium |
test_suite kuralı; orta ölçekli test grubu |
small |
test_suite kuralı; bir dizi küçük test |
smoke |
test_suite kuralı; çalıştırılması gerektiği anlamına gelir.
sürüm kontrol sistemine kod değişiklikleri uygulama |
Çalıştırma dosyaları
Aşağıda, etiketli bir *_binary() kuralı olduğunu varsayın
//foo/bar:unittest (çalışma zamanı bağımlılığı etiketli kurala bağlı)
//deps/server:server.
Konum
Hedef //foo/bar:unittest için Runfiles dizini, dizindir
$(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. Bu yol
runfiles_dir.
Bağımlılıklar
Runfiles dizini,
*_binary() kural. Runfiles dizininin kendisi BUILD kümesine bağlıdır
*_binary() kuralını veya derleme zamanını ya da çalışma zamanını etkileyen dosyalar
ve bildirmeyi konuştuk. Kaynak dosyaların değiştirilmesi
olduğundan, yeniden oluşturmayı tetiklemez.
İçindekiler
Runfiles dizini şunları içerir:
- Çalışma zamanı bağımlılıklarına sembolik bağlantılar:
*_binary()kuralının çalışma zamanı bağımlılığıdır ve tek sembolik bağlantıyı kullanabilirsiniz. Sembolik bağlantının adı:$(WORKSPACE)/package_name/rule_nameÖrneğin, sunucunun sembolik bağlantısı$(WORKSPACE)/deps/server/serverolarak adlandırılır ve tam yol şöyle olur:$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. Sembolik bağlantının hedefi, ExitFile'ın ExitFileName() veya Mutlak yol olarak ifade edilen CommandRule. Bu nedenle, sembolik bağlantı$(WORKSPACE)/linux-dbg/deps/server/42/serverolabilir. - Alt çalıştırma dosyalarının sembolik bağlantıları: Çalışma zamanı olan her
*_binary()Z için*_binary()C bağımlılığıysa çalıştırma dosyalarında ikinci bir bağlantı daha vardır C dizininden Z'nin çalıştırma dosyalarıyla birleştirir. Sembolik bağlantının adı:$(WORKSPACE)/package_name/rule_name.runfilesSembolik bağlantının hedefi: dizin. Örneğin, tüm alt programlar ortak bir çalıştırma dosyasını paylaşır. dizin.