Test yürütme ortamının kapsamlı bir spesifikasyonu.
Arka plan
Bazel BUILD dili, birçok dilde otomatik test programları tanımlamak için kullanılabilecek kurallar içerir.
Testler bazel test kullanılarak çalıştırılır.
Kullanıcılar, test ikililerini doğrudan da çalıştırabilir. 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 açıklanmış bağımlılıklarının olduğu kaynaklara erişmelidir. 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 test çalıştırıcı ve derleme sistemi için de şartlar uygular.
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 yetkili olması amaçlanmıştır. Bu spesifikasyon ile test çalıştırıcısının uygulanan davranışı uyuşmazsa spesifikasyona öncelik verilir.
Ö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, altın çıkışları ve sürüm kontrolünde tutulan diğer her şeyi içerir.) Bir kullanıcı, korunmasını bekledikleri bir sabit değer test etmek zorundadır. Diğer kullanıcılar, değişmezliğin bozulup bozulmadığını kontrol etmek için testi daha sonra yürütür. Öğ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 şunlara 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ışlarının test çalıştırıcı tarafından sabit kalması garanti edilen kaynaklar
Şu anda bu tür davranışlar uygulanmıyor. Ancak test çalıştırıcıları, gelecekte bu tür yaptırımlar ekleme hakkını saklı tutar.
Derleme sisteminin rolü
Test kuralları, her birinin yürütülebilir bir program oluşturması gerektiği açısından ikili kurallara benzer. Bazı diller için bu, dile özgü bir koşum takımı ile test kodunu birleştiren bir stub programdır. Test kuralları başka çıkışlar da üretmelidir. Test çalıştırıcı, birincil test yürütülebilir dosyasına ek olarak çalıştırma dosyalarının manifest dosyasına (çalışma zamanında teste sunulması gereken giriş dosyaları) ihtiyaç duyar ve testin türü, boyutu ve etiketleri hakkında bilgi gerekebilir.
Derleme sistemi, verilerin yanı sıra kodu da yayınlamak için çalıştırma dosyalarını 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.
Testi çalıştıran kullanıcının rolü
Test çalıştırıcı açısından her test, execve() ile çağrılabilecek bir programdır. 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 testin başarısız olduğu anlamına gelir. İç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, bazı kaynak sınırlarını aşarsa veya test çalıştırıcı başka bir şekilde yasaklanmış davranış algılarsa testi sonlandırmayı ve çalıştırmayı başarısızlık olarak değerlendirmeyi seçebilir. Çalıştırıcı, test işlemine veya bu işlemin alt öğelerine sinyal gönderdikten sonra testi başarılı olarak bildirmemelidir.
Test hedefinin tamamına (tek tek yöntemler veya testler değil) tamamlanması için sınırlı bir süre verilir. Bir testin zaman sınırı, aşağıdaki tabloya göre timeout özelliğine bağlıdır:
| Mola | Süre 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 |
Belirli bir zaman aşımı ayarı olmayan "büyük" bir testin çalışması için 900 saniye ayrılır. "Kısa" zaman aşımı olan "orta" bir test için 60 saniye ayrılır.
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. Muhtemelen çok hızlı bir şekilde çok korkunç şeyler yapar.
Testler, zaman aşımından bağımsız olarak keyfi olarak hızlı bir şekilde sonuç döndürebilir. Testler, çok fazla ek süre verildiği için cezalandırılmaz ancak uyarı gönderilebilir. Genellikle, ek sürenizi herhangi bir tutarsızlık oluşturmayacak şekilde olabildiğince kısa ayarlamanız gerekir.
Yavaş olduğu bilinen koşullarda manuel olarak çalıştırıldığında test zaman aşımı, --test_timeout bazel işaretiyle geçersiz kılınabilir. İ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 dakika olarak ayarlar.
Test zaman aşım süreleri için önerilen bir alt sınır da vardır:
| 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. bazel --test_verbose_timeout_warningskomut satırı seçeneğini kullandığınızda, belirtilen boyutu çok büyük olan testler gösterilir.
Test boyutları ve zaman aşımları BUILD dosyasında burada bulabilirsiniz. Belirtilmemişse 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 bölme işlemi aracılığıyla paralelleştirilebilir. 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, parça sayısını, TEST_SHARD_INDEX ise 0'dan başlayan parça dizin numarasını belirtir. Çalıştırıcılar bu bilgileri kullanarak hangi testleri
çok önemlidir. Tüm test çalıştırıcıları parçalamayı desteklemez. 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ı, her testi argv[0] içindeki test yürütülebilir dosyasının yolu ile çağırmalıdır. 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 |
unset | 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, testlerdeki kararsız hataları bildirmek için genel bir mekanizma olarak değil, yalnızca test altyapısından kaynaklanan hataları bildirmek için kullanılmalıdır. Bu bağlamda test altyapısı, teste özgü olmayan ancak düzgün çalışmayarak testin başarısız olmasına neden olabilecek sistemler veya kitaplıklar olarak tanımlanır. İlk satır, hataya neden olan test altyapısı bileşeninin adıdır, ikinci satır ise hatanın insan tarafından okunabilir açıklamasıdır. Ek satırlar yoksayılır.) | isteğe bağlı |
TEST_LOGSPLITTER_OUTPUT_FILE |
Yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (Logsplitter protobuffer günlüğünü yazmak için kullanılır) | isteğe bağlı |
TEST_PREMATURE_EXIT_FILE |
Yazılabilir bir dizindeki özel bir dosyanın mutlak yolu (exit() çağrılarını yakalamak için kullanılır) |
isteğe bağlı |
TEST_RANDOM_SEED |
--runs_per_test seçeneği kullanılırsa TEST_RANDOM_SEED, her bir test çalıştırması için run number değerine (1'den başlayarak) ayarlanır. |
isteğe bağlı |
TEST_RUN_NUMBER |
--runs_per_test seçeneği kullanılırsa TEST_RUN_NUMBER, her bir test çalıştırması için run number değerine (1'den başlayarak) ayarlanır. |
isteğe bağlı |
TEST_TARGET |
Test edilen hedefin adı | isteğe bağlı |
TEST_SIZE |
Test size |
isteğe bağlı |
TEST_TIMEOUT |
Saniye cinsinden test timeout |
isteğe bağlı |
TEST_SHARD_INDEX |
sharding kullanılıyorsa bölüm 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 |
Runfiles 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 (belirtilmemiş yazmak için kullanılır
test çıkışları arasında). TEST_UNDECLARED_OUTPUTS_DIR dizinine yazılan tüm dosyalar sıkıştırılır ve bazel-testlogs altındaki bir outputs.zip dosyasına eklenir. |
isteğe bağlı |
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR |
Yazılabilir özel bir dizinin mutlak yolu (tanımlanmamış test çıkışı .part ve .pb dosyalarını yazmak için kullanılır). |
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 lideri olabilir ya da olmayabilir. Süreçte kontrol terminali olabilir veya olmayabilir. İşlemde sıfır veya daha fazla çalışan ya da toplanmış olmayan alt işlem olabilir. Test kodu kontrolü ele aldığında işlemde birden fazla iş parçacığı olmamalıdır.
Dosya tanımlayıcı 0 (stdin) okunmak için açık olacak, ancak neye ekli olduğu
belirtilmemiş. Testler bu dosyadan okumamalıdır. Dosya tanımlayıcıları 1 (stdout) ve 2 (stderr) yazmaya açık olmalıdır ancak bunlara nelerin eklendiği belirtilmez. 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.
Beklemedeki alarm veya aralıklı zamanlayıcı olmamalıdır.
Engellenen sinyallerin ilk maskesi boş olmalıdı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) ve kaynak kullanımı (getrusage() tarafından döndürülen) belirtilmez.
İlk planlama politikası ve öncelik belirtilmemiştir.
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 bu tür yollara erişmemelidir.
/tmp yazılabilir olmalıdır ancak testlerde bu yolların kullanılmaması gerekir.
Testler, sabit bir yolun yalnızca kendi kullanımları için mevcut olduğunu varsayamaz.
Testler, atimes'in bağlı dosya sistemleri için etkin olduğunu varsayamaz.
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 kullanırsınız. 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ştir.
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. Ana makine adı çözüldüğünde mevcut ana makinenin IP adresi verilmelidir. İlk noktadan sonra kesilen ana makine adının çözümlenmesi de işe yaramalıdır. localhost 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ğinin toplam sayısı istenenden daha fazlaysa Bazel, testi yine de çalıştıracak. Bir testte bölümlendirme kullanılıyorsa her bir bölüm, burada belirtilen CPU çekirdek sayısını ayırır.
Testler alt süreçler 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 değişebilir ancak şu anda on binlerce giriş aralığındadır.
Saat ve tarih
Geçerli saat ve tarih belirtilmemiş. Sistem saat dilimi belirtilmemiş.
X Windows kullanılabilir veya kullanılamayabilir. X sunucusu gerektiren testler başlatılmalıdır Xvfb.
Dosya sistemiyle etkileşimi test edin
Aksi belirtilmedikçe, test ortamı değişkenlerinde belirtilen tüm dosya yolları yerel dosya sisteminin bir yerini işaret eder.
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 içine .part dosyaları da yazabilir.
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ı izleyemez. Testin, aynı anda çalışan diğer testler ve test dışı işlemlerle çakışmasını önlemek için benzersiz yollar kullanması, hermetik olması ve /tmp içinde oluşturduğu dosyaları temizlemesi gerekir.
Ö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 bağlantılar veya bunların bir karışımını içerip içermediği belirtilmez. Çalıştırma dosyası ağacı, dizinlere yönelik sembolik bağlantılar içerebilir.
Testler, çalıştırma dosyalarında .. bileşen içeren yollar kullanmaktan kaçınmalıdır
ağacı.
Runfiles ağacındaki hiçbir dizin, dosya veya sembolik bağlantı (sembolik bağlantıları izleyen yollar dahil) yazılabilir olmamalıdır. (Bunun sonucunda, ilk çalışma dizininin yazılabilir olmaması gerekir.) 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ğlamaları, runfiles ağacındaki bir yolun çözümlenmesinin sonucunu etkileyecek şekilde değiştirilmemelidir.
Erken çıkışı yakalamak için bir test,
Başlangıçta TEST_PREMATURE_EXIT_FILE, çıkışta kaldırın. Bazel, test tamamlandığında dosyayı görürse testin erken sona erdiğini varsayar ve testin başarısız olduğunu işaretler.
Etiket kuralları
Test kurallarındaki bazı etiketlerin özel bir anlamı vardır. Ayrıca, tags özelliğiyle ilgili Bazel Derleme Ansiklopedisi'ne de bakın.
| Etiket | Anlamı |
|---|---|
exclusive |
Aynı anda başka test çalıştırmayın. |
external |
testin dış bağımlılığı vardır. test önbelleğe almayı devre dışı bırak |
large |
test_suite kuralı; kapsamlı testler |
manual * |
:..., :* veya :all gibi joker karakter hedef kalıplarına test hedefini eklemeyin |
medium |
test_suite kuralı; orta düzey testler paketi |
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 |
Runfiles
Aşağıda, //foo/bar:unittest etiketli bir *_binary() kuralı olduğunu ve bu kuralın //deps/server:server etiketli kurala çalışma zamanında bağımlı olduğunu varsayalım.
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ının derleme zamanı bağımlılığı olarak tanımlanır. runfiles dizini, *_binary() kuralını veya derleme veya çalışma zamanındaki bağımlılıklarından herhangi birini etkileyen BUILD dosyası grubuna bağlıdır. Kaynak dosyaların değiştirilmesi
olduğundan yeniden oluşturmayı tetiklemez.
İçindekiler
runfiles dizini şunları içerir:
- Çalışma zamanındaki bağımlılıklara yönelik simge bağlantıları:
*_binary()kuralının çalışma zamanındaki bağımlılıklarından biri olan her OutputFile ve CommandRule, çalışma dosyaları dizininde bir simge bağlantısıyla temsil edilir. Simge bağlantısı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. Simge bağlantısının hedefi, OutputFile veya CommandRule'ın OutputFileName() işlevidir ve mutlak yol olarak ifade edilir. Bu nedenle, sembolik bağlantının hedefi$(WORKSPACE)/linux-dbg/deps/server/42/serverolabilir. - Alt çalışma dosyalarına yönelik sembolik bağlantılar:
*_binary()C'nin çalışma zamanındaki bağımlılığı olan her*_binary()Z için C'nin çalışma dosyaları dizininde Z'nin çalışma dosyalarına giden ikinci bir bağlantı bulunur. Sembolik bağlantının adı:$(WORKSPACE)/package_name/rule_name.runfilesSimge bağlantısının hedefi, runfiles dizinidir. Örneğin, tüm alt programlar ortak bir çalıştırma dosyasını paylaşır. dizin.