Akış
Kırarak Doğrula (Break-to-Verify)
Kırarak Doğrula (Break-to-Verify), üretilen bir testin gerçekten başarısız olabildiğini sınayan kontroldür. Merge’den önce test normal uygulamada, sonra kontrollü bir hata açılmış aynı uygulamada, ardından yine normal uygulamada koşar. Uygulama bozukken yeşil kalan test işaretlenir ve merge edilmesi açık, kayda geçen bir insan kabulü ister.
Yeşil test neden yetmez (Demoda gösterilir)
Geçen yeni bir test tek başına pek bir şey söylemez. Doğru davranışı denetliyor olabilir; ama her zaman doğru olan bir şeyi de denetliyor olabilir: hep görünen bir eleman, yanlış alana yazılmış bir assertion ya da test edilen mantığa hiç ulaşmayan bir adım.
Yapay zekâ (AI) ile üretilen testlerde bu soru daha da önem kazanır. İnceleyenler kodu ve eşlemeyi okur; fakat bir test doğru görünüp yakalaması gereken hataya karşı yine de duyarsız olabilir.
Kırarak Doğrula bu soruyu review yerine bir koşuyla yanıtlar. Fikir mutation testing’e benzer: uygulamayı bilinen bir biçimde değiştirip testin bunu fark edip etmediğine bakmak. Fark kapsamdadır. Mutation testing kodda çok sayıda otomatik değişiklik üretir; Kırarak Doğrula ise test ortamında önceden hazırlanmış, az sayıda bilinçli ve anlamlı hata kullanır.
Kırarak Doğrula deterministiktir ve model kullanmaz; bu yüzden model değerlendirmesi gerektirmez. Güncel etiketi Yetenekler sayfasındadır.
Bir koşu nasıl işler
Mühendis Kırarak Doğrula’yı üretilen testin script sayfasından başlatır. Platform, her biri ayrı kaydedilen üç test koşusu yürütür:
- Yeşil: test normal uygulamada koşar ve geçmelidir.
- Kırmızı: test, yalnızca bu koşu için açılan kontrollü bir hatayla yeniden koşar. Beklenen sonuç, bir assertion’da başarısız olmasıdır.
- Yeniden yeşil: hata kapatılır ve test bir kez daha geçmelidir.
Hata koşuyla sınırlıdır. Referans kurulumda yalnızca o koşunun test kullanıcısına uygulanır; diğer kullanıcılar, diğer koşular ve kod üretim ajanı etkilenmez. Hata anahtarına yalnızca uygulamanın API’si ve özel bir belirteç taşıyan test koşucusu ulaşabilir, ajanın tarayıcısı ulaşamaz.
Portal üç aşamayı, her koşunun sonucuyla birlikte bir zaman çizelgesi olarak gösterir. Kırarak Doğrula’nın oluşturduğu koşular ayrıca etiketlenir ve geçme oranı gibi Kontrol Kulesi (Control Tower) KPI’larına katılmaz.
Sonucu okumak
Bir Kırarak Doğrula koşusu üç durumdan biriyle biter.
| Sonuç | Anlamı | Merge’e etkisi |
|---|---|---|
| Geçti | Yeşil, ardından assertion’da kırmızı, sonra yeşil: test hatayı yakalıyor | Ek adım yok |
| Zayıf | Hata açıkken test yeşil kaldı | Merge açık bir kabul notu ister |
| Başarısız | Bir koşu tamamlanamadı, örneğin ortam sağlıksızdı | Merge açık bir kabul notu ister; yeniden koşmak önerilir |
Zayıf sonuç otomatik bir engel değil, bir işarettir ve çoğu zaman beklenir: iptal süresi kuralındaki bir hata, yalnızca sipariş listesini denetleyen bir testi etkilememelidir. Platform sonucu gizlemez; bir insanın bunu açıkça söylemesini ister.
Kabul notu merge kararının gerekçesi olarak saklanır ve kişi ile zamanla birlikte denetim kaydına yazılır. Kırarak Doğrula sürerken merge reddedilir.
Örnek: STORY-142
Kurgusal Acme Retail web mağazasında test ortamı, iptal kuralı için bir hata anahtarı sunar. Anahtar açıkken uygulama, müşterinin kargoya verilmiş bir siparişi iptal etmesine izin verir.
- “Kargolanmış siparişte İptal yerine İade talebi görünür” testi normal uygulamada yeşil koşar. Hata açıkken kargolanmış siparişte İptal düğmesi belirir ve assertion başarısız olur. Hata kapanınca test yine yeşildir. Sonuç geçti.
- “Sipariş listesi en yeni siparişi önce gösterir” testi de normal uygulamada yeşil koşar. Hata açıkken de yeşil kalır, çünkü sipariş listesi iptal kuralına bağlı değildir. Sonuç zayıf. Mühendis sonucu okur, “İptal kuralıyla ilgisiz; liste sıralaması başka testlerde kapsanıyor” notunu yazar ve merge eder.
İki karar da sonradan görünür kalır. İlk PR geçen bir Kırarak Doğrula sonucu taşır; ikincisi zayıf sonucu mühendisin notuyla birlikte kaydeder.
Neyi kanıtlar, neyi kanıtlamaz
Kırarak Doğrula belirli türde bir kanıt verir; onu tam olarak doğru okumak önemlidir.
Kanıtladıkları:
- Test, açılan o belirli hataya duyarlıdır.
- Kırmızı sonuç bir çökme ya da zaman aşımından değil, bir assertion’dan gelir.
- Hata kaldırılınca test yeşile döner; yani kırmızı koşunun nedeni bozuk bir ortam değildir.
Kanıtlamadıkları:
- Testin özellikteki her hatayı yakaladığı. Yalnızca hazırlanmış hataları kapsar, fazlasını değil.
- Test paketinin bütün olarak iyi kapsama sağladığı. Kırarak Doğrula test test çalışır.
- Uygulamanın hatasız olduğu.
“Geçti” sonucunu “bu test doğru nedenle başarısız olabiliyor” diye okuyun. Kod review’unu ve adım eşlemesini tamamlar; onların yerini tutmaz.
Test ortamınızdan beklenenler
Kırarak Doğrula, test ortamında anlamlı bir hatayı açıp kapatmanın bir yolunu ister. Platform hata oluşturmak için uygulama kodunuzu değiştirmez.
Pratikte bu, test ortamında şu özelliklere sahip küçük bir test kancası ya da özellik bayrağı demektir:
- Bir iş kuralını bilinen bir biçimde değiştirir; örneğin reddedilmesi gereken bir iptali kabul eder.
- Tek bir test kullanıcısıyla ya da tek bir koşuyla sınırlanabilir; böylece paralel işler etkilenmez.
- Yalnızca test ortamlarında bulunur ve yalnızca test koşucusunun taşıdığı bir belirteçle korunur.
Hangi hataların nerede hazırlanacağı pilot sırasında mühendislik ekibiyle birlikte kararlaştırılır. Hazırlanmış hatası olmayan bölümlerin testleri zayıf sonuç verir. Bu beklenen bir durumdur ve insan kabulü adımı testin neden yine de merge edildiğini kayda geçirir.
Merge sonrası ilgili kontroller
Kırarak Doğrula, üretilen bir testin etrafındaki birkaç deterministik kontrolden biridir.
- PR’dan önce: katı TypeScript derlemesi, lint, AST koruması ve yeni testin tekrarlanan koşuları. Tutarsız sonuçlar testi flaky olarak işaretler.
- Merge kapısında: korumalı dalın zorunlu kontrolleri ve bir insan onayı. Dal main’in gerisindeyken de merge engellenir.
- Merge’den sonra: bir push koşusu main’i tam paketle doğrular. PR, push, deploy ve gece tetiklerinin hepsi aynı onaylı paketi yapay zekâ olmadan koşturur; buna CI’da Sıfır AI (Zero-AI CI) diyoruz.
Merge edilmiş bir test daha sonra, elemanın rolü ve adı aynı kalıp yalnızca testId’si değiştiği için başarısız olursa, triage yalnızca locator değerini değiştiren bir Onarım PR’ı (Repair PR) önerir. Beklenen sonucun gerçekleşenden farklı olduğu bir hata asla otomatik onarılmaz; olası bir defect olarak raporlanır.
Güncellendi: