Ansiklopediyi test et

Sorun bildirme Kaynağı görüntüleme Nightly · 8.0 . 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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 çağrı aşağıda açıklanan zorunluluklara uymayacağından bu işleme izin verilir ancak onaylanmamaktadır.

Testler hermetik olmalıdır. Yani yalnızca açıklanmış bağımlılıklarının olduğu kaynaklara erişmelidir. Testler gerektiği gibi hermetik değilse geçmişte tekrar üretilebilir sonuçlar vermez. Bu durum, suçluyu bulma (hangi değişikliğin bir testi bozduğunu belirleme), sürüm mühendisliği denetlenebilirliği ve testlerin kaynak izolasyonu (otomatik test çerçeveleri, bazı testler onunla iletişim kurduğu için bir sunucuya DDOS saldırısı yapmamalıdır) açısından önemli bir sorun olabilir.

Hedef

Bu sayfanın amacı, Bazel testlerinin çalışma ortamı ve beklenen davranışını resmi olarak belirlemektir. Ayrıca test çalıştırıcı ve derleme sistemi için de şartlar uygular.

Test ortamı spesifikasyonu, test yazarlarının belirtilmemiş davranışa güvenmemesini sağlar ve böylece test altyapısına uygulama değişiklikleri yapma konusunda daha fazla özgürlük tanır. Spesifikasyon, şu anda uygun şekilde hermetik, deterministik ve yeniden girişe izin vermemesi rağmen birçok testin geçmesine izin veren bazı boşlukları kapatır.

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

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" ve "OPTIONAL" anahtar kelimeleri, IETF RFC 2119'da açıklandığı şekilde yorumlanmalıdır.

Testlerin amacı

Bazel testlerinin amacı, deposuna kontrol edilen kaynak dosyaların bazı özelliklerini doğrulamaktır. (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ı beklediği bir değişmezliği doğrulamak için bir test yazar. Diğer kullanıcılar, değişmezliğin bozulup bozulmadığını kontrol etmek için testi daha sonra yürütür. Test, kaynak dosyalar dışındaki değişkenlere bağlıysa (hermetik olmayan) değeri azalır. Bunun nedeni, testin geçmemesi durumunda sonraki kullanıcıların değişikliklerinin hatalı olduğundan emin olamamalarından kaynaklanır.

Bu nedenle, bir testin sonucu yalnızca aşağıdakilere bağlı olmalıdır:

  • Testin açıklanmış bir bağımlılığı olduğu kaynak dosyalar
  • Testin bildirilen bir bağımlılığı olduğu derleme sisteminin ürünleri
  • 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 runfiles 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, hem kod hem de veri yayınlamak için çalışma dosyalarını kullanabilir. (Bu, dinamik bağlantı kullanımı gibi testler arasında dosyaları paylaşarak her test ikili dosyasını küçültmek için bir optimizasyon olarak kullanılabilir.) Derleme sistemi, oluşturulan yürütülebilir dosyanın bu dosyaları kaynak veya çıkış ağacındaki mutlak konumlara yönelik kodlanmış referanslar yerine test çalıştırıcı tarafından sağlanan runfiles resmi aracılığıyla yüklediğinden emin olmalıdır.

Testi çalıştıran kişinin rolü

Test çalıştırıcı açısından her test, execve() ile çağrılabilecek bir programdır. Testleri çalıştırmanın başka yolları da olabilir. Örneğin, bir IDE, Java testlerinin işlem sırasında çalıştırılmasına izin verebilir. Ancak testin bağımsız bir işlem olarak çalıştırılmasının sonucu yetkili olarak kabul edilmelidir. Bir test süreci sonuna kadar çalıştırılır ve sıfır çıkış koduyla normal şekilde sonlandırılırsa test geçer. Diğer tüm sonuçlar testin başarısız olduğu anlamına gelir. Özellikle, PASS veya FAIL dizelerinden herhangi birinin stdout'a yazılması test çalıştırıcı için anlamlı değildir.

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

Zaman aşımı açıkça belirtilmeyen testlerde, testin size değerine göre aşağıdaki gibi bir zaman aşımı varsayılır:

beden Varsayılan zaman aşımı etiketi
küçük kısa video
medium orta
büyük uzun
muazzam 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'ten farklı olarak size, Yaygın tanımlar bölümünde açıklandığı gibi, testi yerel olarak çalıştırırken diğer kaynakların (ör. RAM) varsayılan en yüksek kullanımını da belirler.

size ve timeout etiketlerinin tüm kombinasyonları yasaldır. Bu nedenle, "devasa" bir testin zaman aşımının "kısa" olduğu beyan edilebilir. 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. --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" bir test 5, 5 saniyede tamamlanıyorsa timeout = "short" veya size = "small" değerini ayarlayabilirsiniz. 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ı, buradaki spesifikasyona göre BUILD dosyasında belirtilir. Belirtilmemişse testin boyutu varsayılan olarak "orta" olur.

Bir testin ana işlemi sona erer ancak alt işlemlerinden bazıları hâlâ çalışıyorsa test çalıştırıcı, çalıştırmayı tamamlanmış olarak kabul etmeli ve ana işlemde gözlemlenen çıkış koduna göre çalıştırmayı başarı veya başarısızlık olarak saymalıdır. Test çalıştırıcı, başıboş işlemleri sonlandırabilir. Testler bu şekilde işlem sızdırmamalıdır.

Test bölme

Testler, test bölme işlemi aracılığıyla paralelleştirilebilir. Test bölme işlemini etkinleştirmek için --test_sharding_strategy ve shard_count bölümüne bakın. Bölme etkinleştirildiğinde test çalıştırıcı, her bölüm için bir kez başlatılır. 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. Koşucu, hangi testlerin çalıştırılacağını seçmek için bu bilgileri kullanır (ör. sırayla çalıştırma stratejisi). Tüm test çalıştırıcıları parçalamayı desteklemez. Bir çalıştırıcı parçalamayı destekliyorsa TEST_SHARD_STATUS_FILE ile belirtilen dosyanın son değiştirilme tarihini oluşturmalı veya güncellemelidir. Aksi takdirde, --incompatible_check_sharding_support etkinse Bazel, bölümlendirilmişse testi geçemez.

İlk koşullar

Test çalıştırıcı, bir testi çalıştırırken belirli başlangıç koşullarını belirlemelidir.

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 olmalı ve testin mevcut dizininin altında olmalıdır (aşağıya bakın, çalıştırma dosyaları ağacındadır). Test çalıştırıcı, kullanıcı açıkça talep etmediği sürece teste başka bağımsız değişkenler iletmemelidir.

İlk ortam bloğu aşağıdaki gibi oluşturulur:

Değişken Değer Durum
HOME $TEST_TMPDIR değeri önerilen
LANG unset zorunlu
LANGUAGE unset zorunlu
LC_ALL unset zorunlu
LC_COLLATE unset zorunlu
LC_CTYPE unset zorunlu
LC_MESSAGES unset zorunlu
LC_MONETARY unset zorunlu
LC_NUMERIC unset zorunlu
LC_TIME unset zorunlu
LD_LIBRARY_PATH Paylaşılan kitaplıklar içeren dizinlerin iki nokta işaretiyle 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 için destek göstermek üzere 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 Yazılabilir özel bir dizinin mutlak yolu zorunlu
TEST_WORKSPACE yerel deponun çalışma alanı adı isteğe bağlı
TEST_UNDECLARED_OUTPUTS_DIR Yazılabilir özel bir dizinin mutlak yolu (tanımlanmamış test çıkışlarını yazmak için kullanılır). 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 gizli bir dosyanın mutlak yolu (test hedefi uyarılarını yazmak için kullanılır) isteğe bağlı
TESTBRIDGE_TEST_ONLY Belirtilirse --test_filter değerinin isteğe bağlı
TZ UTC zorunlu
USER getpwuid(getuid())->pw_name değeri zorunlu
XML_OUTPUT_FILE Test işlemlerinin test sonucu XML çıkış dosyası yazması gereken konum. Aksi takdirde Bazel, test işleminin bir parçası olarak test günlüğünü sarmalayan varsayılan bir XML çıkış dosyası oluşturur. XML şeması, JUnit test sonucu şemasına dayanır. isteğe bağlı
BAZEL_TEST Test çalıştırılabilir dosyasının bazel test tarafından çalıştırıldığını gösterir. zorunlu

Ortam ek girişler içerebilir. Testler, yukarıda listelenmeyen herhangi bir ortam değişkeninin varlığına, yokluğuna veya değerine bağlı olmamalıdır.

İlk çalışma dizini $TEST_SRCDIR/$TEST_WORKSPACE olmalıdır.

Mevcut işlem kimliği, işlem grubu kimliği, oturum kimliği ve üst işlem kimliği belirtilmemiştir. Süreç, bir süreç grubu lideri veya oturum lideri olabilir ya da olmayabilir. İşlemin kontrol terminali olabilir veya olmayabilir. İşlem, sıfır veya daha fazla çalışan ya da toplanmış olmayan alt işleme sahip olabilir. Test kodu kontrolü ele aldığında işlemde birden fazla iş parçacığı olmamalıdır.

Dosya tanımlayıcısı 0 (stdin) okumaya açık olmalıdır ancak neyin üzerine eklendiği belirtilmez. 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. Terminal, boru, normal dosya veya karakter yazılabilen başka bir şey olabilir. Açık dosya tablosunda bir giriş paylaşabilirler (yani bağımsız olarak arama yapamaz). Testler, diğer açık dosya tanımlayıcılarını devralmamalıdır.

İ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şlemlerine ayarlanır.

Hem yumuşak hem de katı 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ü

Test çalıştırıcısının doğrudan kontrolü altındaki kullanıcı bağlamının özelliklerine ek olarak, testlerin çalıştırıldığı işletim sisteminin de test çalıştırmanın geçerli olması için belirli özellikleri karşılaması gerekir.

Dosya sistemi

Bir test tarafından gözlemlenen kök dizin, gerçek kök dizin olabilir veya olmayabilir.

/proc eklenmelidir.

Tüm derleme araçları, yerel kurulum tarafından kullanılan /usr altındaki mutlak yollarda bulunur.

/home ile başlayan yollar kullanılamayabilir. Testler bu tür yollara erişmemelidir.

/tmp yazılabilir olmalıdır ancak testlerde bu yollar kullanılmamalıdır.

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

root, nobody ve unittest kullanıcıları mevcut olmalıdır. root, nobody ve eng grupları mevcut olmalıdır.

Testler, root olmayan bir kullanıcı olarak yürütülmelidir. Gerçek ve etkili kullanıcı kimlikleri eşit olmalıdır. Grup kimlikleri için de aynı durum geçerlidir. Bunun dışında, mevcut kullanıcı kimliği, grup kimliği, kullanıcı adı ve grup adı belirtilmez. Ek grup kimlikleri kümesi belirtilmemiştir.

Mevcut kullanıcı kimliği ve grup kimliği, getpwuid() ve getgrgid() ile alınabilecek karşılık gelen adlara sahip olmalıdır. Bu durum, ek grup kimlikleri için geçerli olmayabilir.

Geçerli kullanıcının bir ana dizini olmalıdır. Yazılabilir olmayabilir. Testler bu dosyaya yazmaya çalışmamalıdır.

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

Testler için en az bir CPU çekirdeği verilir. Diğer yöntemler kullanılabilir ancak bu garanti edilmez. Bu çekirdeğin diğer performans özellikleri belirtilmemiştir. Bir test kuralına "cpu:n" etiketini (n pozitif bir sayı) ekleyerek rezervasyonu daha yüksek sayıda CPU çekirdeğine artırabilirsiniz. Bir makinede istenenden daha az toplam CPU çekirdeği varsa Bazel yine de testi çalıştırır. 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 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 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 sunucusuna ihtiyaç duyan testler Xvfb'yi başlatmalıdır.

Dosya sistemiyle etkileşimi test etme

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 (ayarlanmışsa) tarafından belirtilen dizinlerde dosya oluşturmalıdır.

Bu dizinler başlangıçta boş olur.

Testler bu dizinleri kaldırmaya, chmod komutunu kullanmaya veya başka bir şekilde değiştirmeye çalışmamalıdır.

Bu dizinler sembolik bağlantılar olabilir.

$TEST_TMPDIR/. dosyasının dosya sistemi türü belirtilmez.

Testler, tanımlanmamış çıkış dosyalarına ek açıklama eklemek için $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR içine .part dosyaları da yazabilir.

Nadir durumlarda, bir testin /tmp içinde dosya oluşturması zorunlu kılınabilir. Örneğin, Unix alan soketlerinin yol uzunluğu sınırlamaları genellikle soketin /tmp altında oluşturulmasını gerektirir. 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.

JUnit4 TemporaryFolder veya Go TempDir gibi bazı popüler test çerçeveleri, /tmp altında geçici dizin oluşturmanın kendi yöntemlerine sahiptir. Bu test çerçeveleri, /tmp'teki dosyaları temizleyen işlevler içerir. Bu nedenle, TEST_TMPDIR dışında dosya oluştursalar bile bunları kullanabilirsiniz.

Testler, girişlere runfiles mekanizması veya yürütme ortamının özellikle giriş dosyalarını kullanılabilir hale getirmek için tasarlanmış diğer bölümleri aracılığıyla erişmelidir.

Testler, kendi yürütülebilir dosyalarının konumundan çıkarılan yollarda derleme sisteminin diğer çıkışlarına erişmemelidir.

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ışma dosyası ağacında .. bileşenleri içeren yollar kullanmaktan kaçınmalıdır.

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, çalıştırma dosyalarının herhangi bir bölümünün yazılabilir olduğunu veya mevcut kullanıcıya ait olduğunu varsayamaz (örneğin, chmod ve chgrp başarısız olabilir).

Çalıştırma dosyası ağacı (simge bağlantılarını izleyen yollar dahil), test çalıştırma sırasında değişmemelidir. Ü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 tarafından belirtilen yolda bir dosya oluşturabilir ve çıkışta bu dosyayı kaldırabilir. 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 harici bir bağımlılığı var; test önbelleğe alma özelliğini devre dışı bırakın
large test_suite kuralı; büyük testler paketi
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ı; küçük testler grubu
smoke test_suite kuralı; kod değişiklikleri sürüm kontrol sistemine commit edilmeden önce çalıştırılması gerektiği anlamına gelir

Çalışma dosyaları

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

//foo/bar:unittest hedefinin runfiles dizini $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles dizinidir. Bu yola runfiles_dir denir.

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, runfiles dizininin yapısını etkilemez ve bu nedenle yeniden derlemeyi 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/server olarak adlandırılır ve tam yolu $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server olur. 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/server olabilir.
  • 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. Simge bağlantısının adı $(WORKSPACE)/package_name/rule_name.runfiles. Simge bağlantısının hedefi, runfiles dizinidir. Örneğin, tüm alt programlar ortak bir çalıştırma dosyası dizini paylaşır.