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 sayfalarına 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 dizinidir. 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 Bazel, parçalanmayı desteklemediğini varsayar ve ek çalıştırıcı başlatmaz.
İ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) | 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/serverolarak adlandırılır ve tam yolu$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/serverolur. 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/serverolabilir. - 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.