Ansiklopediyi test et

Sorun bildir Kaynağı göster

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

Arka plan

Bazel BUILD dili, birçok dilde otomatik test programlarını tanımlamak için kullanılabilecek kurallar içerir.

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

Kullanıcılar, test ikili programlarını doğrudan da yürütebilir. Bu çağrı aşağıda açıklanan zorunluluklara bağlı olmayacağından, buna izin verilir ancak desteklenmez.

Testler hermetik olmalıdır. Yani, yalnızca bağımlı olduğu bildirilen kaynaklara erişebilmelidir. Testler düzgün bir hermetik değilse, geçmişe göre tekrarlanabilir sonuçlar vermez. Bu durum, suçlu bulma (hangi değişikliğin testi başarılı sonuç vermediğini belirleme), yayın mühendisliği denetlenebilirliği ve testlerin kaynak izolasyonu (bazı testler ile ilgili olduğu için otomatik test çerçevelerinin bir sunucuya DDOS'yi algılamaması gerekir) açısından önemli bir sorun olabilir.

Hedef

Bu sayfanın amacı, Bazel testleri için çalışma zamanı ortamını ve beklenen davranışı resmî olarak oluşturmaktır. Ayrıca test çalıştırıcısı ve derleme sistemi için gereklilikler bulur.

Test ortamı spesifikasyonu, test yazarlarının belirtilmemiş davranışa güvenmekten kaçınmasına yardımcı olur ve böylece test altyapısına, uygulama değişiklikleri yapma konusunda daha fazla özgürlük kazandırır. Spesifikasyon, düzgün bir şekilde hermetik, belirleyici ve girişken olmamasına rağmen birçok testin geçmesine izin veren bazı delikleri kapatmaktadır.

Bu sayfa hem normatif hem de güvenilir bir kaynaktır. Bu özellik ile test çalıştırıcının uygulanan davranışı uyuşmazsa spesifikasyon öncelikli olur.

Önerilen özellik

"ZORUNLU", "GEREKLİ", "GEREKMEZ", "GEREKMEZ", "ALIŞMAYACAK", "GEREKMEZ", "ÖNERİLMELİ", "ÖNERİLİR", "MAYIS" ve "İSTEĞE BAĞLI" anahtar kelimeleri IETF RFC 2119'da açıklandığı şekilde yorumlanmalıdır.

Testlerin amacı

Bazel testlerinin amacı, depoya kaydedilen kaynak dosyaların bazı özelliklerini onaylamaktır. (Bu sayfadaki "kaynak dosyalar", test verilerini, altın çıkışları ve sürüm kontrolü altında tutulan diğer her şeyi içerir.) Bir kullanıcı, korunmasını beklediği bir sabiti doğrulamak için bir test yazar. Diğer kullanıcılar, sabit değerin bozuk olup olmadığını kontrol etmek için daha sonra testi yürütür. Test, kaynak dosyalar (hermetik olmayan) dışında herhangi bir değişkene bağlıysa değeri azalır, çünkü sonraki kullanıcılar testin başarılı olması durduğunda değişikliklerinin hatalı olduğundan emin olamazlar.

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

  • testin bildirilmiş bağımlılığı olduğu kaynak dosyalar
  • testin bildirilen bağımlılığı olan derleme sistemi ürünleri
  • test çalıştırıcısı tarafından davranışının sabit kalması garanti edilen kaynakların

Şu anda bu tür bir davranış uygulanmıyor. Ancak test çalıştırıcıları gelecekte bu tür yaptırımlar uygulama hakkını saklı tutar.

Derleme sisteminin rolü

Test kuralları, her birinin yürütülebilir bir program döndürmesi gerektiğinden ikili program kurallarına benzer. Bazı dillerde bu, dile özgü bir grubu test koduyla birleştiren bir saplama programıdır. Test kuralları başka sonuçlar da üretmelidir. Yürütülebilir birincil test dosyasına ek olarak, test çalıştırıcısının runfiles adlı bir manifeste ve çalışma zamanında test için sunulması gereken giriş dosyalarına ihtiyacı vardır ve testin türü, boyutu ve etiketleri hakkında bilgiye ihtiyaç duyabilir.

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

Test çalıştırıcısının rolü

Test çalıştırıcısı açısından her test, execve() ile çağrılabilecek bir programdır. Testleri yürütmenin başka yolları da olabilir. Örneğin, bir IDE, işlem sırasında Java testlerinin yürütülmesine izin verebilir. Bununla birlikte, testin bağımsız bir süreç olarak çalıştırmanın sonucu yetkili olarak kabul edilmelidir. Bir test süreci tamamlanıncaya kadar çalışır ve sıfır çıkış koduyla normal bir şekilde sonlanırsa test başarılı olmuş demektir. Diğer tüm sonuçlar test hatası olarak kabul edilir. Özellikle, PASS veya FAIL dizelerinden herhangi birini stdout'a yazmanın test çalıştırıcısı için herhangi bir önemi yoktur.

Bir testin yürütülmesi çok uzun sürerse, kaynak sınırlarını aşarsa veya test çalıştırıcısı başka şekilde yasaklı bir davranış algılarsa testi sonlandırmayı ve çalıştırmayı hata olarak değerlendirmeyi seçebilir. Çalıştırıcı, test sürecine veya test sürecine sinyal gönderdikten sonra testi başarılı olarak bildirmemelidir.

Test hedefinin tamamına (bağımsız yöntemlere veya testlere değil), testin tamamlanması için sınırlı bir süre verilir. Bir test için süre sınırı, aşağıdaki tabloya göre testin timeout özelliğine bağlıdır:

Mola Süre Sınırı (sn.)
kısa video 60
orta düzey 300
uzun 900
sonsuz 3.600

Açık bir şekilde zaman aşımı belirtmeyen testlerde, testin size parametresine göre aşağıdaki gibi bir ima bulunur:

boy Zaman aşımı etiketi
small kısa video
medium orta düzey
large uzun
devasa sonsuz

Açık bir zaman aşımı ayarı olmayan "büyük" bir testin çalışması için 900 saniye süre verilir. Zaman aşımı "kısa" olan bir "orta" teste 60 saniye süre verilir.

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

size ve timeout etiketlerinin tüm kombinasyonları yasaldır. Bu nedenle, "devasa" bir testin "kısa" zaman aşımına sahip olduğu beyan edilebilir. Herhalde çok hızlı bir şekilde gerçekten korkunç şeyler yapar.

Testler, zaman aşımından bağımsız olarak rastgele bir şekilde geri dönebilir. Çok fazla zaman aşımı olması durumunda teste ceza verilmez ancak bir uyarı gösterilebilir: Genelde herhangi bir görüntüde soruna neden olmadan zaman aşımını 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 flag'i ile geçersiz kılınabilir. --test_timeout değerleri saniye cinsindendir. Örneğin, --test_timeout=120 test zaman aşımını iki dakikaya ayarlar.

Test zaman aşımları için aşağıdaki gibi önerilen bir alt sınır da vardır:

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

Örneğin, "orta" bir test 5, 5 sn içinde tamamlanırsa timeout = "short" veya size = "small" ayarlamayı düşünün. Bazel --test_verbose_timeout_warnings komut satırı seçeneği kullanıldığında belirtilen boyutu çok büyük olan testler gösterilir.

Test boyutları ve zaman aşımları DERLEME dosyasında, buradaki spesifikasyona göre belirtilir. Belirtilmemişse testin boyutu varsayılan olarak "orta" olur.

Bir testin ana süreci çıkış yapıyor ancak bazı alt öğeleri hâlâ çalışıyorsa test yürütücü, çalıştırmayı tamamlanmış kabul etmeli ve ana işlemde gözlemlenen çıkış koduna göre başarılı veya başarısız olarak saymalıdır. Test çalıştırıcısı, sokaktaki tüm süreçleri sonlandırabilir. Testler, süreçleri bu şekilde sızdırmamalıdır.

Parçalama testi

Testler, test parçalama yoluyla paralel hale getirilebilir. Test parçalamayı etkinleştirmek için --test_sharding_strategy ve shard_count sayfalarını inceleyin. Parçalama etkinleştirildiğinde test çalıştırıcı, parça başına bir kez başlatılır. Ortam değişkeni TEST_TOTAL_SHARDS parça sayısıdır; TEST_SHARD_INDEX ise 0'dan başlayan parça dizinidir. Koşucular hangi testlerin çalıştırılacağını seçmek için bu bilgileri kullanır (örneğin, çevrimsel sıralı strateji kullanarak). Tüm test koşucuları parçalamayı desteklemez. Çalıştırıcı, parçalamayı destekliyorsa TEST_SHARD_STATUS_FILE tarafından belirtilen dosyanın son değiştirilme tarihini oluşturmalı veya güncellemelidir. Aksi takdirde, --incompatible_check_sharding_support etkinleştirilirse Bazel, parçalanmışsa testte başarısız olur.

Başlangıç koşulları

Bir testi yürütürken, test çalıştırıcısı belirli başlangıç koşulları belirlemelidir.

Test çalıştırıcı, her testi argv[0] içinde yürütülebilir testin yoluyla çağırmalıdır. Bu yol göreli olmalı ve testin geçerli dizininin altında olmalıdır (runfiles ağacında bulunan aşağıya bakın). Test çalıştırıcı, kullanıcı açık bir şekilde istemediği sürece teste başka bağımsız değişkenler geçirmemelidir.

İlk ortam bloğu aşağıdaki gibi oluşturulmalıdır:

Değişken Değer Durum
HOME $TEST_TMPDIR değeri önerilen
LANG ayarını kaldır zorunlu
LANGUAGE ayarını kaldır zorunlu
LC_ALL ayarını kaldır zorunlu
LC_COLLATE ayarını kaldır zorunlu
LC_CTYPE ayarını kaldır zorunlu
LC_MESSAGES ayarını kaldır zorunlu
LC_MONETARY ayarını kaldır zorunlu
LC_NUMERIC ayarını kaldır zorunlu
LC_TIME ayarını kaldır zorunlu
LD_LIBRARY_PATH Paylaşılan kitaplıklar içeren dizinlerin iki nokta üst üste 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 stabil olmayan 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 özel olmayan ancak arıza nedeniyle 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ıdır. İkinci satır, hatanın kullanıcılar tarafından okunabilen bir 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 (Logplitter protobuffer günlüğü yazmak için kullanılır) isteğe bağlı
TEST_PREMATURE_EXIT_FILE Yazılabilir bir dizindeki özel dosyanın mutlak yolu (exit() öğesine yapılan çağrıları 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 (1 ile başlayan) olarak 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 (1 ile başlayan) olarak 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 timeout testi 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 runfiles ağacının tabanına giden mutlak yol zorunlu
TEST_TOTAL_SHARDS sharding kullanılıyorsa toplam shard count isteğe bağlı
TEST_TMPDIR yazılabilir özel bir dizine giden mutlak yol zorunlu
TEST_WORKSPACE yerel deponun çalışma alanı adı isteğe bağlı
TEST_UNDECLARED_OUTPUTS_DIR yazılabilir özel bir dizine giden mutlak yol (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ılarak bazel-testlogs altındaki outputs.zip dosyasına eklenir. isteğe bağlı
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR yazılabilir özel bir dizine giden mutlak yol (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ı 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 Yürütülebilir testin bazel test tarafından çalıştırıldığını belirtir 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 belirtilmedi. Süreç, bir süreç grubu lideri veya oturum lideri olabilir ya da olmayabilir. İşlemin kontrol terminali olabilir veya olmayabilir. İşlemde, çalışan ya da düzeltilmemiş alt işlem sıfır veya daha fazla olabilir. Test kodu kontrolü ele geçirdiğinde işlemde birden fazla iş parçacığı olmamalıdır.

Dosya tanımlayıcı 0 (stdin) okuma için açık olacak, ancak ekin ne olduğu belirtilmedi. Testler bu klasörden okunmamalıdır. 1 (stdout) ve 2 (stderr) dosya tanımlayıcıları yazmaya açık olacak, ancak bu tanımlayıcıların ne olduğu belirtilmemiş. Bir terminal, boru, normal dosya veya karakterlerin yazılabileceği başka herhangi bir şey olabilir. Açık dosya tablosundaki bir girişi 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ık zamanlayıcısı olmayacak.

Engellenen sinyallerin başlangıç maskesi boş olmalıdır. Tüm sinyaller varsayılan işlemlerine ayarlanacaktır.

Hem yumuşak hem de sert olan başlangıç 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 belirtilmedi.

Ana makine sisteminin rolü

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

Dosya sistemi

Testte gözlemlenen kök dizin, gerçek kök dizin olabilir veya olmayabilir.

/proc eklenecek.

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

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

/tmp yazılabilir olacaktır ancak testler bu yolları kullanmaktan kaçınmalıdır.

Testler, bunların münhasır kullanımları için sabit bir yolun mevcut olduğunu varsaymamalıdır.

Testler, eklenmiş herhangi bir dosya sisteminde atimes özelliğinin etkinleştirildiğini varsaymamalıdır.

Kullanıcılar ve gruplar

Kullanıcıların root, nobody ve unittest öğeleri mevcut olmalıdır. Gruplar kökü, hiç kimse ve eng mevcut olmalıdır.

Testler, kök olmayan kullanıcı olarak yürütülmelidir. Gerçek ve etkili kullanıcı kimlikleri, aynı şekilde grup kimlikleri için de eşit olmalıdır. Bunun ötesinde mevcut kullanıcı kimliği, grup kimliği, kullanıcı adı ve grup adı belirtilmemiştir. Ek grup kimlikleri grubu belirtilmemiştir.

Geçerli kullanıcı kimliği ve grup kimliği, getpwuid() ve getgrgid() ile alınabilecek karşılık gelen adlara sahip 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, üzerine yazmaya çalışmamalıdır.

Ağ İletişimi

Ana makine adı belirtilmedi. Nokta içerebilir veya içermeyebilir. Adın çözümlenmesinde geçerli ana makinenin IP adresi verilmelidir. İlk noktadan sonra kesilen ana makine adını çözmek de işe yarayacaktır. localhost ana makine adı çözümlenmelidir.

Diğer kaynaklar

Testlere en az bir CPU çekirdeği verilmiş. Bazıları kullanılabilir ancak bu garanti edilmez. Bu çekirdeğin diğer performans özellikleri belirtilmemiş. Bir test kuralına "cpu:n" etiketini (burada n pozitif sayıdır) ekleyerek rezervasyonu daha yüksek CPU çekirdeği sayısına artırabilirsiniz. Bir makinenin toplam CPU çekirdeği istenenden azsa Bazel yine de testi çalıştırır. Bir test parçalama kullanıyorsa her bir parça, burada belirtilen CPU çekirdeği sayısını ayırır.

Testler alt işlemler oluşturabilir, ancak grupları veya oturumları işleme koyamaz.

Testin tüketebileceği giriş dosyası sayısı için bir sınır vardı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 belirtilmedi. Sistem saat dilimi belirtilmedi.

X Windows kullanılabilir veya bulunmayabilir. X sunucusu gerektiren testler Xvfb'yi başlatmalıdır.

Dosya sistemiyle etkileşimi test et

Test ortamı değişkenlerinde belirtilen tüm dosya yolları, aksi belirtilmedikçe yerel dosya sisteminde bir yere 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ş olacaktır.

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

Bu dizinler sembolik bağlantılar olabilir.

$TEST_TMPDIR/. dosya sistemi türü belirtilmedi.

Testler, bildirilmemiş çıkış dosyalarına not eklemek için $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR öğesine .part dosyaları da yazabilir.

Nadir durumlarda, testin /tmp ürününde dosya oluşturulması zorunlu kılınabilir. Örneğin, Unix alan yuvaları için yol uzunluğu sınırları genellikle yuvanın /tmp altında oluşturulmasını gerektirir. Bazel bu tür dosyaları izleyemez. Testin kendisinin hermetik olmasına, aynı anda yürütülen diğer testler ve test dışı işlemlerle çakışmamak için benzersiz yollar kullanmaya ve /tmp içinde oluşturduğu dosyaları temizlemeye dikkat etmesi gerekir.

JUnit4 TemporaryFolder veya Go TempDir gibi bazı popüler test çerçeveleri, /tmp altında geçici bir dizin oluşturmak için kendi yöntemlerine sahiptir. Bu test çerçeveleri, /tmp içindeki dosyaları temizleyen işlev içerir. Dolayısıyla, TEST_TMPDIR dışında dosyalar oluştursalar bile bunları kullanabilirsiniz.

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

Testler, kendi yürütülebilir dosyalarının konumundan belirlenen 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 belirtilmemiştir. Runfiles ağacı, dizinlere yönlendiren sembolik bağlantılar içerebilir. Testler, runfiles ağacında .. bileşenlerini içeren yolları kullanmaktan kaçınmalıdır.

Runfiles ağacındaki hiçbir dizin, dosya veya sembolik bağlantı (sembolik bağlantılardan geçen yollar dahil) yazılabilir olmamalıdır. (İlk ç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 geçerli kullanıcıya ait olduğunu varsaymamalıdır (örneğin, chmod ve chgrp başarısız olabilir).

Runfiles ağacı (sembolik bağlantılardan geçen yollar dahil) test işlemi sırasında değişmemelidir. Üst dizinler ve dosya sistemi bağlantıları hiçbir şekilde değişmemelidir. Bu durum, çalıştırma dosyaları ağacı içindeki bir yolun çözümlenmesinin sonucunu etkiler.

Erken çıkışı yakalamak için test, başlangıçta TEST_PREMATURE_EXIT_FILE tarafından belirtilen yolda bir dosya oluşturup çıkışta bu dosyayı kaldırabilir. Test bittiğinde Bazel dosyayı görürse testten erken çıkış yapıldığını varsayar ve testi başarısız olarak işaretler.

Etiket kuralları

Test kurallarındaki bazı etiketlerin özel bir anlamı vardır. tags özelliğinde Bazel Derleme Ansiklopedisi'ni de inceleyin.

Etiket Anlamı
exclusive aynı anda başka test çalıştırma
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 karakter hedef kalıplarına test hedefi eklemeyin
medium test_suite kuralı; orta düzeyde test grubu
small test_suite kuralı; küçük testler paketi
smoke test_suite kuralı; sürüm kontrol sisteminde kod değişiklikleri yapılmadan önce çalıştırılması gerektiği anlamına gelir

Çalıştırma dosyaları

Aşağıda //foo/bar:unittest etiketli bir *_binary() kuralı bulunduğunu ve //deps/server:server etiketli kuralda çalışma zamanı bağımlılığı olduğunu varsayalım.

Konum

Hedef //foo/bar:unittest için runfiles dizini, $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles dizinidir. Bu yol, runfiles_dir olarak adlandırılır.

Bağımlılıklar

Runfiles dizini, *_binary() kuralının derleme zamanı bağımlılığı olarak tanımlanır. Runfiles dizininin kendisi, *_binary() kuralını veya derleme zamanı ya da çalışma zamanı bağımlılıklarından herhangi birini etkileyen DERLEME dosyaları grubuna bağlıdır. Kaynak dosyaların değiştirilmesi çalıştırma dosyaları dizininin yapısını etkilemez ve bu nedenle herhangi bir yeniden oluşturma işlemi tetiklenmez.

İç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ığı olan her ExitFile ve CommandRule, çalıştırma dosyaları dizinindeki bir sembolik bağlantıyla temsil edilir. Sembolik bağlantının adı $(WORKSPACE)/package_name/rule_name. Örneğin, sunucu 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, mutlak yol olarak ifade edilen ExitFile veya CommandRule'ın ExitFileName() öğesidir. Bu nedenle, sembolik bağlantının hedefi $(WORKSPACE)/linux-dbg/deps/server/42/server olabilir.
  • Alt çalıştırma dosyalarının sembolik bağlantıları: *_binary() C'nin çalışma zamanı bağımlılığı olan her *_binary() Z için C'nin çalıştırma dosyaları dizininde, Z'nin çalıştırma dosyalarına 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.