Ansiklopediyi test et

Sorun bildir Kaynağı görüntüle Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Test yürütme ortamının kapsamlı bir spesifikasyonu.

Arka plan

Bazel BUILD dilinde, birçok dilde otomatik test programları tanımlamak için kullanılabilecek kurallar bulunur.

Testler bazel test kullanılarak çalıştırılır.

Kullanıcılar test ikililerini doğrudan da çalıştırabilir. Bu tür bir çağırma işlemi aşağıda açıklanan zorunluluklara uymayacağından bu işleme izin verilir ancak desteklenmez.

Testler hermetik olmalıdır. Yani yalnızca bağımlılık beyan ettikleri kaynaklara erişmelidirler. Testler düzgün şekilde hermetik değilse geçmişte tekrarlanabilir sonuçlar vermez. Bu durum, suçluyu bulma (hangi değişikliğin testi bozduğunu belirleme), yayın mühendisliği denetlenebilirliği ve testlerin kaynak yalıtımı (bazı testler sunucuyla iletişim kurduğu için otomatik test çerçeveleri sunucuya hizmet reddi saldırısı yapmamalıdır) açısından önemli bir sorun olabilir.

Hedef

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

Test ortamı spesifikasyonu, test yazarlarının belirtilmemiş davranışlara güvenmesini önlemeye yardımcı olur ve böylece test altyapısına uygulama değişiklikleri yapma konusunda daha fazla özgürlük tanır. Bu spesifikasyon, şu anda birçok testin hermetik, deterministik ve yeniden girişli olmamasına rağmen geçmesine izin veren bazı boşlukları kapatır.

Bu sayfa hem normatif hem de yetkili bir kaynak olarak tasarlanmıştır. Bu spesifikasyon ile test çalıştırıcının uygulanan davranışı arasında uyuşmazlık varsa spesifikasyon önceliklidir.

Önerilen Spesifikasyon

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

Testlerin amacı

Bazel testlerinin amacı, depoya kaydedilen kaynak dosyaların belirli bir özelliğini doğrulamaktır. (Bu sayfada "kaynak dosyalar" ifadesi; test verilerini, altın çıktıları ve sürüm denetimi altında tutulan diğer tüm öğeleri kapsar.) Bir kullanıcı, korunmasını beklediği bir değişmezi onaylamak için test yazar. Diğer kullanıcılar, değişmezin bozulup bozulmadığını kontrol etmek için testi daha sonra yürütür. Test, kaynak dosyalar dışında herhangi bir değişkene bağlıysa (hermetik olmayan) değeri azalır. Bunun nedeni, test geçmeyi bıraktığında sonraki kullanıcıların değişikliklerinin hatalı olduğundan emin olamamasıdır.

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

  • Testin bağımlı olduğu belirtilen kaynak dosyalar
  • Testin üzerinde bildirilen bağımlılığa sahip olduğu derleme sisteminin ürünleri
  • Davranışının test çalıştırıcı tarafından sabit kalacağı garanti edilen kaynaklar

Şu anda bu tür davranışlar zorunlu kılınmamaktadır. Ancak test çalıştırıcılar, gelecekte bu tür bir zorunluluk ekleme hakkını saklı tutar.

Derleme sisteminin rolü

Test kuralları, her birinin yürütülebilir bir program oluşturması gerektiği için ikili kurallara benzer. Bazı dillerde bu, dile özgü bir test düzeneğini test koduyla birleştiren bir taslak programdır. Test kuralları başka çıktı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ına ihtiyaç duyar ve testin türü, boyutu ve etiketleri hakkında bilgiye ihtiyaç duyabilir.

Derleme sistemi, kodun yanı sıra verileri de sunmak için runfiles'ı kullanabilir. (Bu, testler arasında dosya paylaşımı yapılarak her test ikilisini küçültmek için optimizasyon olarak kullanılabilir. Örneğin, dinamik bağlantı kullanılarak.) Derleme sistemi, oluşturulan yürütülebilir dosyanın bu dosyaları kaynak veya çıkış ağacındaki mutlak konumlara yönelik sabit kodlanmış referanslar yerine test çalıştırıcı tarafından sağlanan runfiles görüntüsü aracılığıyla yüklemesini sağlamalıdır.

Test çalıştıranın rolü

Test çalıştıran açısından her test, execve() ile çağrılabilen bir programdır. Testleri yürütmenin başka yolları da olabilir. Örneğin, bir IDE, Java testlerinin işlem içinde yürütülmesine izin verebilir. Ancak testi bağımsız bir işlem olarak çalıştırmanın sonucu yetkili olarak kabul edilmelidir. Bir test süreci tamamlanıp sıfır çıkış koduyla normal şekilde sonlandırılırsa test başarılı olur. Diğer tüm sonuçlar test hatası olarak kabul edilir. Özellikle, PASS veya FAIL dizelerinden herhangi birinin stdout'a yazılmasının test çalıştırıcı için bir önemi yoktur.

Bir testin yürütülmesi çok uzun sürerse, bazı kaynak sınırlarını aşarsa veya test çalıştırıcı yasaklanmış davranış tespit ederse testi sonlandırmayı ve çalıştırmayı başarısız olarak değerlendirmeyi seçebilir. Çalıştırıcı, test sürecine veya alt süreçlerine 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 süre 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
ebedi 3600

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

beden Örtülü zaman aşımı etiketi
small kısa video
medium orta
large uzun
çok büyük ebedi

Açık bir zaman aşımı ayarı olmayan "büyük" bir testin çalışması için 900 saniye ayrılır. Zaman aşımı "kısa" olan bir "orta" testine 60 saniye ayrılır.

timeout'dan farklı olarak size, testi yerel olarak çalıştırırken diğer kaynakların (ör. RAM) varsayılan en yüksek kullanımını da belirler. Bu durum, Ortak tanımlar bölümünde açıklanmıştır.

size ve timeout etiketlerinin tüm kombinasyonları geçerlidir. Bu nedenle, "çok büyük" bir testin zaman aşımı "kısa" olarak ilan edilebilir. Muhtemelen çok hızlı bir şekilde korkunç şeyler yapacaktır.

Testler, zaman aşımı süresinden bağımsız olarak rastgele hızlı sonuçlar döndürebilir. Test, çok uzun bir zaman aşımı nedeniyle cezalandırılmaz ancak uyarı verilebilir. Genellikle zaman aşımınızı, kararsızlığa neden olmadan olabildiğince kısa tutmanız gerekir.

Yavaş olduğu bilinen koşullar altında 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şımları için önerilen bir alt sınır da vardır:

Mola Minimum süre (sn.)
kısa video 0
orta 30
uzun 300
ebedi 900

Örneğin, "orta" zorluktaki bir test 5, 5 saniyede tamamlanıyorsa timeout = "short" veya size = "small" ayarını yapmayı düşünebilirsiniz. Bazel --test_verbose_timeout_warnings komut 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 sonlandırılır ancak alt işlemlerinden bazıları hâlâ çalışıyorsa test çalıştırıcı, çalıştırmanın tamamlandığını düşünmeli ve ana işlemden gözlemlenen çıkış koduna göre bunu başarılı veya başarısız olarak saymalıdır. Test çalıştırıcı, başıboş işlemleri sonlandırabilir. Testler bu şekilde süreçleri sızdırmamalıdır.

Test parçalama

Testler, test parçalama yoluyla paralelleştirilebilir. Test parçalama özelliğini etkinleştirmek için --test_sharding_strategy ve shard_count dokümanlarına bakın. Parçalama etkinleştirildiğinde test çalıştırıcı, her parça için bir kez başlatılır. TEST_TOTAL_SHARDS çevre değişkeni parça sayısıdır ve TEST_SHARD_INDEX, 0'dan başlayan parça dizinidir. Çalıştırıcılar, hangi testlerin çalıştırılacağını seçmek için bu bilgileri kullanır (ör. sırayla çalıştırma stratejisi kullanır). Bazı test çalıştırıcılar parçalama özelliğini desteklemez. Bir çalıştırıcı parçalama özelliğini destekliyorsa TEST_SHARD_STATUS_FILE ile belirtilen dosyanın son değiştirme tarihini oluşturması veya güncellemesi gerekir. Aksi takdirde, --incompatible_check_sharding_support etkinse Bazel, parçalanmışsa testi başarısız kılar.

Başlangıç koşulları

Test yürütülürken test çalıştırıcısı belirli başlangıç koşulları oluşturmalıdır.

Test çalıştırıcı, her testi argv[0] içindeki test yürütülebilir dosyasının yoluyla çağırmalıdır. Bu yol, göreceli olmalı ve testin mevcut dizininin altında olmalıdır (runfiles ağacında bulunur, aşağıya bakın). Test çalıştırıcı, kullanıcı açıkça istemediği sürece teste başka bağımsız değişkenler iletmemelidir.

Başlangıçtaki 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 ü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 test altyapısından kaynaklanan hataları bildirmek için kullanılmalıdır. Testlerin kararsız hatalarını bildirmek için genel bir mekanizma olarak kullanılmamalıdır.) Bu bağlamda, test altyapısı, teste özgü olmayan ancak arızalanarak test hatalarına neden olabilecek sistemler veya kitaplıklar olarak tanımlanır. İlk satır, hataya neden olan test altyapısı bileşeninin adını, ikinci satır ise hatanın insan tarafından okunabilir açıklamasını içerir. Ek satırlar yoksayılır.) isteğe bağlı
TEST_LOGSPLITTER_OUTPUT_FILE Yazılabilir bir dizindeki özel 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 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 her bir test çalıştırması için TEST_RANDOM_SEED, run number olarak ayarlanır (1'den başlar). isteğe bağlı
TEST_RUN_NUMBER --runs_per_test seçeneği kullanılırsa her bir test çalıştırması için TEST_RUN_NUMBER, run number olarak ayarlanır (1'den başlar). isteğe bağlı
TEST_TARGET Test edilen hedefin adı isteğe bağlı
TEST_SIZE size testi isteğe bağlı
TEST_TIMEOUT Saniye cinsinden test timeout isteğe bağlı
TEST_SHARD_INDEX sharding kullanılıyorsa parça dizini isteğe bağlı
TEST_SHARD_STATUS_FILE sharding desteğini belirtmek için dokunulacak dosya yolu isteğe bağlı
TEST_SRCDIR çalıştırma dosyaları ağacının tabanının mutlak yolu zorunlu
TEST_TOTAL_SHARDS total 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 Özel bir yazılabilir dizinin mutlak yolu (bildirilmemiş 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 outputs.zip dosyasına eklenir. isteğe bağlı
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR Özel yazılabilir bir dizinin mutlak yolu (bildirilmemiş test çıkışı ek açıklaması .part ve .pb dosyalarını yazmak için kullanılır). isteğe bağlı
TEST_WARNINGS_OUTPUT_FILE Yazılabilir bir dizindeki özel dosyanın mutlak yolu (test hedefi uyarılarını yazmak için kullanılır) isteğe bağlı
TESTBRIDGE_TEST_ONLY Belirtilmişse --test_filter değeri 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ını yazması gereken konum. Aksi takdirde Bazel, test işlemi kapsamında test günlüğünü içeren varsayılan bir XML çıkış dosyası oluşturur. XML şeması, JUnit test sonucu şemasına dayanmaktadır. isteğe bağlı
BAZEL_TEST Test yürütülebilir dosyasının bazel test tarafından çalıştırıldığını gösterir. zorunlu

Ortamda ek girişler olabilir. 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ş. İşlem, işlem grubu lideri veya oturum lideri olabilir ya da olmayabilir. İşlemin kontrol terminali olabilir veya olmayabilir. İşlemde sıfır veya daha fazla çalışan ya da tamamlanmamış alt işlem olabilir. Test kodu kontrolü ele aldığında süreçte birden fazla iş parçacığı olmamalıdır.

Dosya tanımlayıcısı 0 (stdin) okuma için açık olmalıdır ancak neye bağlı olduğu belirtilmemiştir. Testler bu dosyadan okuma yapmamalıdır. Dosya tanımlayıcıları 1 (stdout) ve 2 (stderr) yazma için açık olmalıdır ancak neye bağlı oldukları belirtilmemiştir. Bu, bir terminal, boru, normal dosya veya karakterlerin yazılabileceği başka bir şey olabilir. Açık dosya tablosunda bir giriş paylaşabilirler (yani bağımsız olarak arama yapamazlar). Testler, başka açık dosya tanımlayıcılarını devralmamalıdır.

İlk umask 022 veya 027 olmalıdır.

Bekleyen 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 geçici hem de kesin olan ilk 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üldüğü şekliyle) ve kaynak kullanımı (getrusage() tarafından döndürüldüğü şekliyle) belirtilmemiştir.

İlk planlama politikası ve önceliği belirtilmemiş.

Ana makine sisteminin rolü

Test çalıştırıcısının doğrudan kontrolü altındaki kullanıcı bağlamı yönlerinin yanı sıra, testlerin yürütüldüğü işletim sistemi de test çalıştırmasının geçerli olması için belirli özellikleri karşılamalıdır.

Dosya sistemi

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

/proc takılmalıdır.

Tüm derleme araçları, yerel bir yükleme tarafından kullanılan /usr altındaki mutlak yollarda bulunmalıdır.

/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ılmasından kaçınılmalıdır.

Testler, özel kullanımları için sabit bir yolun mevcut olduğunu varsaymamalıdır.

Testler, bağlı dosya sistemleri için atime'ların etkinleştirildiğini varsaymamalıdır.

Kullanıcılar ve gruplar

root, nobody ve unittest kullanıcıları mevcut olmalıdır. Gruplar kökü, nobody ve eng 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ı belirtilmemiştir. Ek grup kimlikleri kümesi belirtilmemiş.

Mevcut kullanıcı kimliği ve grup kimliğinin, getpwuid() ve getgrgid() ile alınabilen karşılık gelen adları olmalıdır. Aynı 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ının çözümlenmesi, mevcut ana makinenin IP adresini vermelidir. Ana makine adının ilk noktadan sonraki kısmının çözümlenmesi de çalışmalıdır. Ana makine adı localhost çözümlenmelidir.

Diğer kaynaklar

Testlere en az bir CPU çekirdeği verilir. Başka yöntemler de kullanılabilir ancak bu garanti edilmez. Bu çekirdeğin diğer performans yönleri belirtilmemiştir. "cpu:n" etiketini (burada n pozitif bir sayıdır) bir test kuralına ekleyerek rezervasyonu daha yüksek bir CPU çekirdeği sayısına çıkarabilirsiniz. Bir makinede istenenden daha az toplam CPU çekirdeği varsa Bazel testi yine de çalıştırır. Bir testte parçalama kullanılıyorsa her bir parça, burada belirtilen sayıda CPU çekirdeğini ayırır.

Testler alt işlemler oluşturabilir ancak işlem grupları veya oturumlar oluşturamaz.

Bir testin kullanabileceği giriş dosyalarının 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ş. Sistemin saat dilimi belirtilmemiş.

X Windows kullanılabilir veya kullanılamayabilir. X sunucusu gerektiren testler Xvfb ile başlatılmalıdır.

Dosya sistemiyle etkileşimi test etme

Aksi belirtilmediği sürece, test ortamı değişkenlerinde belirtilen tüm dosya yolları yerel dosya sistemindeki bir konuma işaret eder.

Testler, yalnızca $TEST_TMPDIR ve $TEST_UNDECLARED_OUTPUTS_DIR ile belirtilen dizinlerde (ayarlanmışsa) dosya oluşturmalıdır.

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

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

Bu dizinler sembolik bağlantılar olabilir.

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

Testler, bildirilmemiş çıkış dosyalarına açıklama eklemek için $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR dosyalarına .part dosyaları da yazabilir.

Nadir durumlarda, bir testin /tmp içinde dosya oluşturması gerekebilir. Örneğin, Unix alan soketleri için yol uzunluğu sınırları genellikle soketin /tmp altında oluşturulmasını gerektirir. Bazel bu tür dosyaları izleyemez. Testin kendisi, eşzamanlı olarak çalışan diğer testler ve test dışı işlemlerle çakışmayı önlemek için benzersiz yollar kullanmak ve /tmp içinde oluşturduğu dosyaları temizlemek üzere hermetik olmaya özen göstermelidir.

JUnit4 TemporaryFolder veya Go TempDir gibi bazı popüler test çerçevelerinin, /tmp altında geçici bir dizin oluşturmak için kendi yöntemleri vardır. Bu test çerçeveleri, /tmp içindeki dosyaları temizleyen işlevler içerir. Bu nedenle, TEST_TMPDIR dışında dosyalar oluşturmalarına rağmen 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.

Çalıştırma dosyaları ağacının normal dosyalar, sembolik bağlantılar veya bunların bir karışımını içerip içermediği belirtilmemiştir. Çalıştırma dosyaları ağacı, dizinlere yönelik sembolik bağlantılar içerebilir. Testlerde, runfiles ağacında .. bileşenlerini içeren yollar kullanılmamalıdır.

Çalıştırma dosyaları ağacındaki hiçbir dizin, dosya veya sembolik bağlantı (sembolik bağlantılardan geçen yollar dahil) yazılabilir olmamalıdır. (Bu nedenle, ilk çalışma dizini yazılabilir olmamalıdır.) Testler, runfiles'ın herhangi bir bölümünün yazılabilir veya mevcut kullanıcıya ait olduğunu varsaymamalıdır (örneğin, chmod ve chgrp başarısız olabilir).

Çalıştırma dosyaları ağacı (sembolik bağlantılardan geçen yollar dahil) test yürütme 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 bittiğinde dosyayı görürse testin erken çıktığını varsayar ve başarısız olarak işaretler.

Etiket kuralları

Test kurallarındaki bazı etiketlerin özel bir anlamı vardır. Ayrıca, Bazel Build Encyclopedia'daki tags özelliği başlıklı makaleyi de inceleyin.

Etiket Anlamı
exclusive aynı anda başka test çalıştırmayın
external testin harici bir bağımlılığı var; test önbelleğe almayı devre dışı bırakın
large test_suite kuralı; büyük testler paketi
manual * :..., :* veya :all gibi joker karakterli hedef kalıplarına test hedefi eklemeyin.
medium test_suite kuralı; orta testler paketi
small test_suite kuralı; küçük testler paketi
smoke test_suite kuralı; kod değişiklikleri sürüm kontrol sistemine işlenmeden önce çalıştırılması gerektiği anlamına gelir.

Runfiles

Aşağıdaki örnekte, //foo/bar:unittest etiketli bir *_binary() kuralının olduğunu ve //deps/server:server etiketli kurala çalışma zamanı bağımlılığı olduğunu varsayalım.

Konum

//foo/bar:unittest hedefinin runfiles dizini, $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles dizinidir. Bu yola runfiles_dir adı verilir.

Bağımlılıklar

Runfiles dizini, *_binary() kuralının derleme zamanı bağımlılığı olarak beyan edilir. Çalıştırma dosyaları dizini, *_binary() kuralını veya derleme zamanı ya da çalışma zamanı bağımlılıklarını etkileyen BUILD dosyaları grubuna bağlıdır. Kaynak dosyaların değiştirilmesi, runfiles dizininin yapısını etkilemez ve bu nedenle yeniden oluşturmayı tetiklemez.

İçindekiler

Çalıştırma dosyaları dizini şunları içerir:

  • Çalışma zamanı bağımlılıklarına yönelik sembolik bağlantılar: *_binary() kuralının çalışma zamanı bağımlılığı olan her OutputFile ve CommandRule, runfiles dizininde bir sembolik bağlantıyla temsil edilir. Sembolik bağlantının adı $(WORKSPACE)/package_name/rule_name. Örneğin, server için sembolik bağlantı $(WORKSPACE)/deps/server/server olarak adlandırılır ve tam yol $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server olur. Sembolik bağlantının hedefi, OutputFile veya CommandRule'un OutputFileName() değeridir 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ı bağımlılığı olan her *_binary() Z için C'nin çalışma dosyaları dizininde Z'nin çalışma dosyalarına yönelik ikinci bir bağlantı bulunur. Sembolik bağlantının adı $(WORKSPACE)/package_name/rule_name.runfiles. Sembolik bağlantının hedefi, runfiles dizinidir. Örneğin, tüm alt programlar ortak bir runfiles dizinini paylaşır.