Ansiklopediyi test et

Sorun bildirin Kaynağı göster

Test yürütme ortamı için kapsamlı bir spesifikasyon.

Arka plan

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

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 tür bir ç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ılıkları bildirilmiş olan kaynaklara erişebilmelidir. Testler gerektiği gibi hermetik değilse, geçmişe dönük olarak tekrarlanabilir sonuçlar vermez. Bu durum; nedenli bulma (hangi değişikliğin testi bozduğunu belirleme), sürüm mühendisliği denetlenebilirliği ve testlerin kaynak izolasyonu (bazı testler ile ilgili olduğu için otomatik test çerçeveleri DDoS olmamalıdır) açısından önemli bir sorun olabilir.

Hedef

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

Test ortamı spesifikasyonu, test yazarlarının belirtilmemiş davranışlara 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 sunar. Bu spesifikasyon; düzgün bir şekilde hermetik, deterministik ve referans olmasa da birçok testin geçilmesine olanak tanıyan bazı delikleri sıkılaştırır.

Bu sayfanın hem normatif hem de güvenilir olması amaçlanmıştır. Bu spesifikasyon ile test çalıştırıcının uygulanan davranışı uyuşmuyorsa spesifikasyona öncelik verilir.

Önerilen Spesifikasyon

"ZORUNLU", "ZORUNLU OLMAMALIDIR", "GEREKLİ", "YAPILMAYACAK", "GEREKMELİ", "GEREKLİ", "KULLANILMAMALIDIR", "ÖNERİLİR", "OLASI" ve "İSTEĞE BAĞLI" anahtar kelimeleri IETF RFC 2119'da açıklandığı şekilde yorumlanmalıdır.

Testlerin amacı

Bazel testlerinin amacı, depoya girilen kaynak dosyaların bazı özelliklerini doğrulamaktı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 sabit değeri doğrulamak için bir test yazar. Diğer kullanıcılar, değişkenin bozulup bozulmadığını daha sonra kontrol etmek için testi yürütür. Test, kaynak dosyalar dışında (hermetik olmayan) herhangi bir değişkene dayanıyorsa, testin geçişi durdurulduğunda sonraki kullanıcılar değişikliklerinin hatalı olduğundan emin olamayacağı için dosyanın değeri azalır.

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ı gelecekte bu tür bir yaptırım ekleme hakkını saklı tutar.

Derleme sisteminin rolü

Test kuralları, her birinin yürütülebilir bir program üretmesi gerektiğinden ikili kurallara benzer. Bazı dillerde bu, dile özgü bir kullanımı test koduyla birleştiren bir saplama programıdır. Test kuralları başka çıkışlar da üretmelidir. Test çalıştırılabilir birincil teste ek olarak, test çalıştırıcının bir runfiles manifesti, çalışma zamanında test için sunulması gereken giriş dosyaları gerekir. Ayrıca testin türü, boyutu ve etiketleri hakkında bilgi de gerekebilir.

Derleme sistemi, çalıştırma dosyalarını ve verilerin yanı sıra kodu da yayınlamak için kullanabilir. (Bu, dosyaları testler arasında paylaşarak (ör. dinamik bağlantı kullanma gibi) her bir test ikili programı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 koda gömülmüş referanslar yerine test çalıştırıcısı tarafından sağlanan çalıştırma dosyası görüntüsü aracılığıyla yüklemesini sağlamalıdır.

Test çalıştırıcı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, devam eden Java testlerinin yürütülmesine izin verebilir. Bununla birlikte, testin bağımsız bir süreç olarak çalıştırılmasının sonucu yetkili olarak kabul edilmelidir. Bir test işlemi tamamlanana kadar çalışır ve sıfır değerinde bir çıkış koduyla normal bir şekilde sonlandırılırsa test geçmiştir. 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ısı için bir önemi yoktur.

Bir testin yürütülmesi çok uzun sürerse, bir kaynak sınırını aşarsa veya test çalıştırıcı başka bir şekilde yasaklanan bir davranış tespit ederse testi sonlandırmayı ve çalıştırmayı başarısız olarak değerlendirmeyi tercih edebilir. Koşucu, test sürecine veya test sürecinin alt öğelerine sinyal gönderdikten sonra testi başarılı olarak bildirmemelidir.

Test hedefinin tamamı (tek tek yöntemler veya testler değil) tamamlanana kadar çalıştırılması için sınırlı bir süre verilir. Bir testin zaman sınırı, aşağıdaki tabloya göre timeout özelliğine göre belirlenir:

Mola Zaman Sınırı (sn.)
kısa video 60
orta 300
uzun 900
sonsuz 3.600

Açıkça bir zaman aşımı belirtmeyen testler, testin size değerine bağlı olarak aşağıdaki gibi bir zaman aşımı belirtir:

beden Dolaylı zaman aşımı etiketi
small kısa video
medium orta
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 tanınır. "Kısa" zaman aşımına sahip bir "orta" test için 60 saniye süre tanınır.

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

size ve timeout etiketlerinin tüm kombinasyonları yasaldır. Bu nedenle, "çok büyük" bir testin "kısa" zaman aşımına sahip olduğu açıklanabilir. Muhtemelen çok hızlı bir şekilde çok korkunç şeyler yapar.

Testler, zaman aşımından bağımsız olarak rastgele hızlı bir şekilde döndürülebilir. Aşırı uzun bir zaman aşımı nedeniyle test cezalandırılmaz, ancak bir uyarı gönderilebilir: Zaman aşımını genellikle herhangi bir sorun yaşamadan olabildiğince kısa tutmanız gerekir.

Yavaş olduğu bilinen koşullar altında manuel olarak çalışırken, 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.

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üzeyde" 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ı BUILD dosyasında buradaki spesifikasyona göre belirtilir. Belirtilmemişse testin boyutu varsayılan olarak "orta" olur.

Bir testin ana süreci çıksa da bazı alt öğeleri hâlâ çalışıyorsa test koşucusu, çalıştırmayı tamamlanmış olarak kabul etmeli ve ana işlemde gözlemlenen çıkış koduna göre bunu başarılı ya da başarısız olarak saymalıdır. Test çalıştırıcısı sürpriz işlemleri sonlandırabilir. Testler, süreçleri bu şekilde sızdırmamalıdır.

Test kırma

Testler, test parçalama yöntemiyle paralel hale getirilebilir. Test parçalamayı etkinleştirmek için bkz. --test_sharding_strategy ve shard_count. 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 bu bilgileri hangi testleri çalıştıracaklarını seçmek için kullanırlar (örneğin, döner sıralama stratejisi kullanarak). Tüm test çalıştırıcıları kırmayı desteklemez. Parçalamayı destekleyen bir çalıştırıcı, TEST_SHARD_STATUS_FILE ile 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 test yürütürken test çalıştırıcının bazı başlangıç koşulları belirlemesi gerekir.

Test çalıştırıcısının, argv[0] içindeki test yürütülebilir yolunun bulunduğu her bir testi çağırması gerekir. Bu yol göreli olmalı ve testin geçerli dizininin (runfiles ağacında, aşağıya bakın) altında olmalıdır. Test çalıştırıcı, kullanıcı açıkça talep etmediği sürece teste başka bağımsız değişken iletmemelidir.

İ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 test altyapısından kaynaklanan hataları bildirmek için kullanılmalıdır, 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 özgü olmayan ancak hatalı çalışarak 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, ikinci satır ise 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 (Günlük Oluşturucu proto arabellek 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ı yakalamak için kullanılır) isteğe bağlı
TEST_RANDOM_SEED --runs_per_test seçeneği kullanılıyorsa her test çalıştırması için TEST_RANDOM_SEED, run number olarak (1 ile başlayan) ayarlanır. isteğe bağlı
TEST_RUN_NUMBER --runs_per_test seçeneği kullanılıyorsa her test çalıştırması için TEST_RUN_NUMBER, run number olarak (1 ile başlayan) ayarlanı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 (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 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 bir dosyanın mutlak yolu (test hedef uyarılarını yazmak için kullanılır) isteğe bağlı
TESTBRIDGE_TEST_ONLY belirtilirse --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 bir 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 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ığına, yokluğuna veya değerine bağlı olmamalıdır.

İ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 belirtilmedi. Süreç, bir süreç grubu lideri veya oturum lideri olabilir ya da olmayabilir. Süreçte kontrol terminali olabilir veya olmayabilir. Süreç, hiç ya da daha fazla çalışan veya tamamlanmamış alt işlem içerebilir. Test kodu kontrolü ele geçirdiğinde süreçte birden fazla iş parçacığı olmamalıdır.

Dosya tanımlayıcısı 0 (stdin) okunmaya açık olmalıdır ancak neye ekli olduğu belirtilmemiştir. Testler buradan okunmamalıdır. Dosya tanımlayıcıları 1 (stdout) ve 2 (stderr) yazmaya açık olacak ancak bunların neye ekli olduğu belirtilmemiş. Bu, bir terminal, dikey çizgi, normal dosya veya karakterlerin yazılabileceği başka bir şey olabilir. Açık dosya tablosunda bir girişi paylaşabilirler (yani bağımsız olarak arama yapamazlar). Testler başka bir açık dosya tanımlayıcısı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ş olacaktır. Tüm sinyaller varsayılan işlemlerine ayarlanacaktı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ülen şekilde) belirtilmemiş.

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

Ana makine sisteminin rolü

Test çalıştırıcının doğrudan kontrolü altındaki kullanıcı bağlamı özelliklerine ek olarak, üzerinde testlerin yürütüleceği işletim sisteminin de test çalıştırmasının geçerli olabilmesi 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 eklenecek.

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ılmaması gerekir.

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

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 engin olması gerekir.

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

Geçerli kullanıcı kimliği ve grup kimliğinin getpwuid() ve getgrgid() ile alınabilen karşılık gelen adları 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, test üzerine yazma girişiminde bulunmamalıdır.

Ağ İletişimi

Ana makine adı belirtilmedi. Nokta içerebilir veya içermeyebilir. Ana makine adını çözümlemek, mevcut ana makinenin IP adresini vermelidir. İlk noktadan sonra ana makine adı kesimini çözmenin de işe yaraması gerekir. Yerel ana makine adı çözümlenmelidir.

Diğer kaynaklar

Testlere en az bir CPU çekirdeği verilir. Başka özellikler de kullanılabilir ancak bu garanti edilmez. Bu çekirdeğin diğer performans yönleri belirtilmemiştir. Bir test kuralına "cpu:n" (burada n pozitif bir sayıdır) etiketini ekleyerek rezervasyonu daha yüksek bir CPU çekirdeği sayısına artırabilirsiniz. Bir makinenin toplam CPU çekirdeği istenenden daha azsa Bazel testi yine de çalıştırır. Bir testte parçalama kullanılıyorsa her bir kırık burada belirtilen CPU çekirdeklerinin 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 belirtilmedi.

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

Dosya sistemiyle etkileşimi test edin

Test ortamı değişkenlerinde belirtilen tüm dosya yolları, aksi belirtilmedikçe yerel dosya sistemindeki 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ı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 açıklama eklemek için $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR bölümüne .part dosyaları da yazabilir.

Nadir durumlarda, bir testle /tmp içinde dosya oluşturulması zorunlu olabilir. Örneğin, Unix alan soketleri için yol uzunluğu sınırları genellikle yuvanın /tmp altında oluşturulmasını gerektirir. Bazel bu tür dosyaları izleyemeyecektir. Testin kendisinin hermetik olması, aynı anda çalışan ve test dışı diğer işlemlerle çakışmaması ve /tmp ürününde oluşturduğu dosyaların temizlenmesi için benzersiz yollar kullanılması gerekir.

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

Testler, girişlere runfiles mekanizması veya yürütme ortamının özel olarak giriş dosyalarını kullanılabilir hale getirmek amacıyla tasarlanan diğer bölümleri aracılığıyla erişmelidir.

Testler, kendi yürütülebilir dosyalarının konumundan tahmin edilen 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 ilişkin sembolik bağlantılar içerebilir. Testler, çalıştırma dosyaları ağacı içinde .. bileşenleri içeren yollar kullanmaktan kaçınmalıdır.

Çalıştırma dosyaları ağacındaki hiçbir dizin, dosya veya sembolik bağlantı (simgesel bağlantılardan geçen yollar dahil) yazılabilir olmamalıdır. (İlk çalışma dizininin yazılabilir olmaması gerektiği anlamına gelir.) 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).

Test yürütme sırasında çalışma dosyaları ağacı (sembol bağlantılardan geçen yollar dahil) değişmemelidir. Üst dizinler ve dosya sistemi eklemeleri, çalıştırma dosyaları ağacı içindeki bir yolun çözümlenmesinin sonucunu etkileyecek herhangi bir şekilde değişmemelidir.

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 zamanından önce çıkıldığı varsayılır ve testin başarısız olduğu belirtilir.

Etiket kuralları

Test kurallarındaki bazı etiketlerin özel bir anlamı vardır. Ayrıca bkz. tags özelliğinde Bazel Build Ansiklopedi.

Etiket Anlamı
exclusive aynı anda başka test çalıştırma
external testin harici bağımlılığı var; test önbelleğe almayı devre dışı bırakın
large test_suite kuralı; büyük test paketi
manual * :..., :* veya :all gibi joker karakter hedef kalıplarına test hedefini dahil etme
medium test_suite kuralı; orta düzeyde test paketi
small test_suite kuralı; küçük test paketi
smoke test_suite kuralı; bu kuralın, 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ğıdaki örnekte, //foo/bar:unittest etiketli ve //deps/server:server etiketli kurala çalışma zamanı bağımlılığı olan bir *_binary() kuralı 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ı etkileyen BUILD dosyaları kümesine veya bunun derleme zamanı ya da çalışma zamanı bağımlılıklarından herhangi birine bağlıdır. Kaynak dosyaların değiştirilmesi, Runfiles dizininin yapısını etkilemez. Bu nedenle, herhangi bir yeniden oluşturma işlemi 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ığı olan her Çıktı Dosyası ve CommandRule, çalıştırma dosyaları dizininde tek bir sembolik bağlantıyla temsil edilir. Sembolik bağlantının adı: $(WORKSPACE)/package_name/rule_name. Örneğin, sunucunun sembolik bağlantısı $(WORKSPACE)/deps/server/server olarak adlandırılır, tam yol ise $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server olur. Sembolik bağlantının hedefi, Çıktı Dosyasının veya CommandRule'ün ÇıktıDosyasıAdı() şeklindedir ve mutlak yol olarak ifade edilir. Bu nedenle sembolik bağlantının hedefi $(WORKSPACE)/linux-dbg/deps/server/42/server olabilir.
  • Alt çalıştırma dosyalarına sembolik bağlantılar: *_binary() C'nin çalışma zamanı bağımlılığı olan her *_binary() Z için C'nin runfiles 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.