backend davranışını kanıtla

Temsili bir fixture'ı gerçek backend runtime'ından geçir, kanıtı yakala ve promote etmeden önce pass mi fail mi karar ver.

TL;DR

• Bir kanıt, bir test-ve-doğrula döngüsüdür: temsili bir fixture gerçek backend runtime'ından geçer, beklenen davranışı üretir ve yakalanabilir runtime sinyalleri bırakır. "Derlendi" bir kanıt değildir.
• Döngünün, neyi kanıtladığından bağımsız olarak aynı şekli vardır — yeni bir component release'i, eğitilmiş bir model artifact'i, bir veri-pipeline backend'i, bir graph revizyonu: test edilen birimi belirle, fixture'ları dondur, onları gerçek runtime'dan geçir, çıktıları ve runtime sinyallerini topla, semantik beklentilere karşı karşılaştır, kanıtı kaydet.
• Bir kanıt, bir backend'in operasyon geçmişini pinler, böylece test ettiğin belirli sürüm sonradan adreslenebilir kalır — "dün test ettiğimiz sürüm" tam bir graph'a çözümlenir. Tekrarlanabilirlik, aynı graph'a, aynı pinlenmiş release'lere ve aynı fixture'lara karşı yeniden oynatan event-sourced operasyon log'undan gelir.
• Platform, kanıtı tekrarlanabilir kılan ilkelleri sağlar — pinlenmiş release'ler, deterministik graph'lar, geçici test backend'leri için yalıtılmış lease'ler, container log'ları — ve "geçer"in tanımını sana bırakır. Beklentileri sen tanımlarsın; platform onları tekrarlanabilir yapar.
• Semantik doğruluk şemadan daha çok önemlidir. Yanlış etiketlerle geçerli JSON yayan bir dedektör bozuktur; yanlış dilde iyi biçimli metin üreten bir transkripsiyon modeli bozuktur. Kanıt, şekille değil anlamla ilgilidir.
• Kanıt promote'tan önce gelir. Aynı fixture seti aday ve mevcut sürüme karşı çalışır; delta, promote kararının dayandığı kanıttır.

Bir kanıt modu seç

Dört başlangıç noktası — kanıtladığın şeye uyanı aç. Her biri onu taşıyan akışa bağlanır.

Kanıt nedir

Bir kanıt, bir değişikliği — bir component release'i, bir model artifact'i, bir veri-pipeline backend'i, bir graph revizyonu — o değişiklik üretime ya da promote'a ulaşmadan önce tekrarlanabilir kanıta dönüştüren adlandırılmış, tekrarlanabilir bir döngüdür. Çıktı, kaydedilmiş bir sonuçtur: test edilen birim, fixture, beklenen davranış, gözlemlenen davranış, runtime sinyali ve bir sonuç.

Kanıtı kendi döngüsünde tutmak, kanıtı tekrarlanabilir kılan şeydir. Her promote kanıt ister; o kanıt, gerçek trafiğin göreceği aynı runtime'da, aynı pinlenmiş sürümlere karşı aynı fixture'ları yeniden çalıştırmalıdır. Bir backend'in operasyon geçmişi bir event-sourced log'dur, böylece test ettiğin graph sonradan adreslenebilir — log aynı graph'a oynatır ve "dün test ettiğimiz sürüm" hareketli bir hedef yerine tam bir operasyon kümesine işaret eder.

Kanıt, unit-test anlamında test etmekten farklıdır. Unit testler kodu yalıtımda çalıştırır; bir kanıt gerçek graph'ı gerçek runtime'da temsili input'larla çalıştırır. Bir unit test geçebilir, entegre sistem başarısız olurken, çünkü test entegrasyonu hiç görmedi. Bir kanıt her zaman entegrasyonu görür, çünkü entegrasyon, içinden geçtiği tek şeydir.

Kanıt sayılan nedir

Bir kanıt altı şey kaydeder; herhangi birini atlamak elinde bir sonuç bırakır, kanıt değil:

Kanıt	Ne kaydedilir	Neden önemli
Test edilen birim	component sürüm ID'si, model artifact ID'si, backend ID'si (veya onu mutasyona uğratan operasyon seti), fixture kimliği	"OCR component'i" yeterince spesifik değil; released sürüm öyle
Input	Fixture'ın kendisi, adreslenebilir ve değişmez	Gelecek çeyrek aynı fixture'a karşı yeniden çalıştıramayacağın bir kanıt tekrarlanabilir değildir
Beklenen davranış	Çıktının ne anlama gelmesi gerektiği, ne şekle sahip olması gerektiği değil	"Görüntüdeki yüzleri algılar" semantiktir; "bir JSON dizisi döner" yalnızca yapısaldır
Gözlemlenen çıktı	runtime'dan yakalanan gerçek yanıt, üretilen dosyalar dahil	Beklentiye karşı karşılaştırdığın şey budur
runtime sinyali	Container log'ları, hata satırları, gecikme gözlemleri	Onsuz soğuk başlatma uçurumları, aralıklı arızalar ve kaynak tükenmesi gizli kalır
Sonuç	Pass / fail / uyuşmazlık, belirli riskler adlandırılmış	Bir risk notu olmayan "Pass", çalışmanın işletmediği fixture parçalarını gizler

Platform altısı için de ilkelleri açığa çıkarır; onları kanıta dönüştürmek kanıt döngüsünün işidir.

Kanıt modları ayrıntılı

Farklı başlangıç noktaları farklı kanıt biçimleri üretir. Yukarıdaki kartlar doğrudan her akışa bağlanır; aşağıdaki bölümler her modun ne zaman doğru olduğunu ve kanıtını neyin savunulabilir kıldığını açıklar.

Bir test backend'inden canlı fixture

Test edilen birim bir component release'i veya bir graph değişikliği olduğunda ve otomatik temizlemeli hızlı tekrarlanabilir bir çalışma istediğinde bu modu kullan.

Bu, component yazarları için varsayılan moddur. Kısa ömürlü bir lease, aday component'i saran bir test backend'i ayağa kaldırır, fixture'ı çalıştırır, çıktıları ve container log'larını yakalar ve söker. lease, yalıtım sınırıdır: test çalışmasının hiçbir yanı üretim graph'larına ya da üretim deployment'larına dokunmaz ve aday sürüm tam olarak gerçek bir backend'in işleteceği gibi işletilir.

Test backend'i üretimle aynı backend ilkellerini kullandığından kanıt sadıktır: tipli stream'ler adaydan akar, component aynı container'laştırılmış ortamı, aynı SDK yardımcılarını, aynı serving-service bağımlılıklarını görür. "Bu unit testte çalışır ama runtime farklı" boşluğu yoktur.

Bkz. Bir canlı backend ile test et ve Lease'ler.

Model bağlı backend'e karşı aynı fixture'lar

Test edilen birim bir model artifact'i olduğunda bu modu kullan: ağırlıklar, checkpoint, ONNX dosyası, adapter veya fine-tune.

Model kanıtı nadiren "JSON üretiyor mu"dur. "Önemsediğimiz input'larda doğru çıktıyı üretiyor mu"dur. Döngü şudur: aday artifact'i yükle, onu hedef backend vertex'inin dosya slot'una bağla, fixture setini çalıştır, gözlemlenen çıktıları semantik beklentiye karşı karşılaştır. Bir modeli yükseltirken kanıt, aynı backend'de önceki artifact'e karşı tekrarlanır ve delta, promote kararı için artifact'tir.

Bu modun "canlı fixture"dan ayrı olmasının nedeni, test edilen birimin component değil, artifact olmasıdır. Aynı component'ten, aynı graph'tan, aynı fixture setinden geçen iki model artifact'i, artifact'i değişken olarak yalıtır — ve o yalıtım, "bu artifact mevcuttan daha iyi"yi savunulabilir kılan şeydir.

Bkz. Model artifact entegrasyonu ve Modeller.

backend'den tekrarlanabilir veri fixture'ı

Test edilen birim bir veri pipeline'ı olduğunda bu modu kullan.

Veri-pipeline kanıtı, fixture-kapsama kanıtıdır: temsili input'lar backend'den geçirilir, üretilen çıktılar yakalanır ve çalışma sonraki regresyon baseline'ı olarak ele alınır. backend tipli bir gerçek zamanlı graph olduğundan, kanıt döngüsünün ayrı bir batch işleme harness'ına ihtiyacı yoktur — üretimde planlı trafiği çalıştıran aynı backend, fixture'ı kanıtta çalıştırır.

Bu modun kendi satırı olmasının nedeni, artifact yakalama alışkanlığıdır: pipeline kanıtları, üretilen çıktılar sökümden sağ çıkıp sonraki çalışmanın beklenen çıktıları olduğunda en faydalıdır. deployment söküm, üretilen dosyaları açıkça workspace dosya deposuna kaydedebilir, ki bu, pipeline kanıtını altta yatan component'lerin sürümleri arasında tekrarlanabilir kılan şeydir.

Bkz. Veri pipeline otomasyonu ve Dosya yükleme ve bağlama.

Sürüm karşılaştırması

promote sorusu "aday mevcuttan daha mı iyi" olduğunda bu modu kullan.

Sürüm karşılaştırması, aynı fixture seti, iki kez çalıştırılmış, iki pinlenmiş birime karşı (iki component sürümü, iki model artifact'i, iki backend revizyonu), her iki gözlemlenen çıktıya aynı semantik ölçütler uygulanmış halidir. Sonuç deltadır, çalışmaların herhangi biri yalıtımda değil. "İyi" ama mevcuttan kötü olan bir aday promote edilmemeli; "kusurlu" ama mevcuttan önemli ölçüde daha iyi olan bir aday genelde edilmeli.

Platform sürüm karşılaştırmasını ucuz kılar çünkü her şey pinlenmiş ve değişmezdir. Fixture adreslenebilirdir; test edilen iki birim adreslenebilirdir; runtime, bir bağlaması değiştirilmiş aynı backend graph'ıdır. "Yanlışlıkla farklı bir fixture'a karşı mı karşılaştırdık" hata modu yoktur.

Bkz. Release semantiği.

Kanıt döngüsü hareket halinde

Minimum sıra kısadır ve tüm modlarda aynı görünür:

1. Test edilenin tam olarak ne olduğunu belirle (sürüm ID'leri, artifact ID'leri, backend ID'si).
2. Aynı input'ların sonradan yeniden çalıştırılabilmesi için fixture setini dondur.
3. Fixture'ı gerçek runtime'dan geçir — component/graph kanıtı için lease destekli bir test backend'i, model/pipeline kanıtı için deploy edilmiş bir backend.
4. Input göndermeden önce her vertex container'ı running raporlayana dek bekle; URL'ler, altta yatan container'lar dinlemeye başlamadan önce çözümlenebilir.
5. Fixture'ı gönder, gözlemlenen çıktıyı topla (varsa üretilen dosyalar dahil), ona eşlik eden container log'larını yakala.
6. Gözlemlenen davranışı semantik beklentiyle karşılaştır.
7. Kanıtı kaydet — ID'ler, fixture, beklenen, gözlemlenen, runtime sinyali, sonuç, uyuşmazlık riskleri.

runtime hatalı davrandığında, container log'ları gerçeğin kaynağıdır. Platform bilerek birleşik bir "yanlış giden buydu" yüzeyi sentezlemez; container çıktısını harfiyen açığa çıkarır ve neyin bir arıza sinyali sayıldığına kanıt döngüsünün karar vermesini bırakır.

Kanıt promote'u neden kapı arkasına alır

promote — bir prerelease'i released bir sürüme dönüştürmek, bir model artifact'ini üretime takmak, gerçek trafiği yeni bir backend revizyonuna yönlendirmek — bir değişikliğin gerçek trafiğe hizmet etmeye başladığı adımdır. Geri alınabilirdir ama geri almak, ancak bir regresyon zaten fark edildikten sonra yardımcı olur.

Kanıt promote'u kapı arkasına alır çünkü diğer kontroller promote'un bağlı olduğu soruları yanıtlayamaz: kod incelemesi sana bir modelin zor bir input alt kümesinde gerileyip gerilemediğini söyleyemez, geçen bir build sana yeni component'in container'ının soğuk başlatmada takılıp takılmadığını söyleyemez, manuel bir smoke test sana şema-doğru bir yanıtın hâlâ aynı anlama gelip gelmediğini söyleyemez. Kanıt taşıyan bir kanıt döngüsü söyleyebilir.

Platform promote'u açık, ayrı bir komut olarak tutar — asla publish'te örtük, asla deploy'da örtük değil. promote çağrısı, bir insanın kararını kanıt döngüsünün ürettiği kanıta iliştirdiği yerdir.

İlgili

• Bir canlı backend ile test et — varsayılan test-harness modu.
• Lease'ler — geçici test backend'leri için yalıtım sınırı.
• Model artifact entegrasyonu — model bağlı kanıt döngüsü.
• Veri pipeline otomasyonu — pipeline kanıt döngüsü.
• Release semantiği — promote'un gerçekte neyi değiştirdiği.
• Deploy et ve izle — kanıt sırasında runtime sinyali yakalama.
• Sık karşılaşılan hatalar — belirti → düzeltme araması.