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 --test_sharding_strategy
ve shard_count
bölümlerine bakın. 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 dizine giden mutlak yol (bildirilmemiş test çıkışlarını yazmak için kullanılır) | 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.