Kod üretimi

Kod üretimi, onaylı test senaryolarını (test case) reponuzdaki Playwright testlerine dönüştürür. Bir ajan her adımı çalışan uygulamada doğrular ve page object kütüphanenize eşler; kod bu eşlemeden şablonla üretilir. Model TypeScript yazmaz; her test, bir insanın inceleyip merge ettiği bir PR (pull request, değişiklik isteği) olarak gelir.

Önkoşullar

Kod üretimi, test kod tabanınızda zaten olan yapının üzerine kurulur. İlk koşudan önce repoda şunlar bulunmalıdır:

• Playwright page object kütüphanesi. Üretilen testler page object metotlarını ve locator’ları (eleman bulucuları) çağırır; yeni seçici uydurmaz. Platform kütüphaneyi bir sembol tablosuna okur ve her adımı mevcut bir sembole eşler.
• Kararlı testId’ler. Testlerin etkileştiği elemanlarda kararlı test kimlikleri olmalıdır. testId tabanlı locator’lar, elemanın rolü ve erişilebilir adıyla birlikte, sonradan deterministik onarımı mümkün kılar.
• Erişilebilir bir test ortamı. Tarayıcı ajanı ve test koşucusu uygulamanın test ortamına ulaşabilmelidir.
• Korumalı bir main dalı. Zorunlu kontrollerle korunan ana dal, merge’lerin review’dan geçmesini sağlar.

Page object kütüphanesi ya da testId’ler yoksa bunları kurmak pilotun ilk adımıdır. Bugün kod üretimi Playwright ile web uygulamaları için kullanılabilir. Masaüstü ve mobil kod üretimi yol haritasındadır (son bölüme bakın).

Üretim koşusunu başlatmak (Demoda gösterilir)

Mühendis bir ya da birkaç onaylı test case seçer ve üretimi başlatır. Bir case ancak şu koşullarda üretime uygundur:

• Onaylanmış ya da yayınlanmıştır.
• İçerik hash’i hâlâ onaylanan hash’e eşittir.
• Story’nin (Jira’daki kullanıcı hikâyesi) PO onayı hâlâ geçerlidir.

Aynı onaylı içerik için açık ya da merge edilmiş bir PR varsa case yeniden üretilmez. Her yeni üretim, güncel main’den yeni bir dal ve yeni bir PR açar. Aynı case için daha önce açılmış PR’a yorum yazılır ve kapatılır.

Örnek story STORY-142 Sipariş iptali için mühendis üç onaylı case seçebilir: ödenmiş siparişi iptal etmek, kargolanmış siparişte “İade talebi” görünmesi ve sürenin tam sonunda iptal. Kod ajanının canlı model değerlendirmesi beklemededir. Güncel etiket Yetenekler sayfasındadır.

Doğrulama ajanı

Her case için bir ajan, Playwright MCP üzerinden bir tarayıcıyla adımları gerçek uygulamada tek tek yürür. Ajanın araçları sıkı biçimde sınırlıdır:

• Yalnızca izin listesindeki tarayıcı araçları kullanılabilir. Rastgele kod çalıştıran, betik değerlendiren ya da dosya okuyan araçlar modele hiç verilmez.
• Gezinme uygulamanın kaynağıyla sınırlıdır; ajanın tarayıcısı yalnızca test edilen uygulamaya ulaşabilir.
• Her koşuda araç çağrısı sayısı sınırlıdır.
• Ajan kendine ayrılmış bir test kullanıcısı kullanır. Sepet gibi paylaşılan durum her doğrulamadan önce sıfırlanır ve doğrulamalar sırayla koşar.

Her adım aracıyla, argümanlarıyla (gizli alanlar maskelenir), kısa bir özetle ve bir ekran görüntüsüyle kaydedilir. Ekran görüntüleri model döngüsünün dışında alınır ve inceleyen kişi için kanıt olarak saklanır; modele gönderilmez.

Ajanın ürettiği her locator page object sembol tablosuyla çapraz kontrol edilir. Bilinen bir sembolle eşleşmeyen adım doğrulanmamış sayılır, PR açılmaz ve case insana düşer.

Şablona bağlı kod

Modelin işi, case adımlarından page object sembollerine doğrulanmış bir eşlemeyle biter. TypeScript dosyası bundan sonra modelle değil, şablonla üretilir.

• Adımlar, kütüphanenizdeki mevcut page object metotlarına ve locator’lara çağrıya dönüşür.
• Değerler yalnızca tür denetimli literal olarak yerleştirilir; böylece case metni şablona kod enjekte edemez.
• Assertion değerleri onaylı case metninden gelir, ajanın gözlemlediğinden değil. Uygulama farklı bir şey gösterirse test başarısız olur; amaçlanan da budur.
• Her case, üretilmiş testler klasöründe story ve case adını taşıyan tek bir spec dosyası üretir.

STORY-142 için örnek bir sonuç şöyle görünür:

test('STORY-142 C2: paid order can be cancelled', async ({ orders }) => {
  await orders.open('A-1001');
  await orders.cancelButton.click();
  await expect(orders.status).toHaveText('Cancelled');
});

Her adımı, page object sembolünü ve değerinin onaylı case’te geçip geçmediğini gösteren eşleme tablosu, portalda kodun yanında ve PR açıklamasında yer alır.

Yerel kontroller

PR açılmadan önce toolchain, üretilen dosya üzerinde bir dizi deterministik kontrol koşturur:

• Katı kipte tsc ve eslint.
• Değişikliğin yapısını bot PR kurallarına göre denetleyen AST koruması. Aynı koruma CI’da (sürekli entegrasyon) zorunlu kontrol olarak yeniden koşar.
• Yeni testin test ortamına karşı birkaç kez tekrarlanan Playwright koşusu.

Sonuç şöyle sınıflanır:

Sonuç	Ne olur
Tüm kontroller geçer	PR açılır
Aynı test hem geçer hem kırmızı verir	Flaky olarak işaretlenir; PR yok
Test bir assertion’da tutarlı biçimde kırmızı	Defect adayı olarak işaretlenir; PR yok
İnsan değişiklik istedi ya da reddetti	İnsan reddi olarak kaydedilir

Bu kontrolleri yürüten toolchain servisi kendisi hiç kod çalıştırmaz. Koşuları internet erişimi ve sırrı olmayan, yalıtılmış bir test koşucusuna gönderir.

Defect adayları

Defect adayı, kod üretiminin en değerli sonuçlarından biridir. Testin story’de onaylanan davranışı beklediğini, bugünkü uygulamanın ise tutarlı biçimde başka bir şey yaptığını gösterir.

STORY-142 örneğinde, analistin gereksinim incelemesinde “onay e-postası eksik” bulgusunu kod hatası olarak işaretlediğini düşünün. “İptal edilen sipariş onay e-postası gönderir” case’i amaçlanan davranışa göre üretilir ve yerel koşusu her tekrarda kırmızı verir. Test, beklenen değeri gerçekleşen değerin yanında gösterir.

Platform testi yeşile boyamaya çalışmaz. Assertion’ı değiştirmez, PR açmaz. Aday insana gider ve triage sırasında inceleme bulgusundan doğan bug taslağına bağlanabilir. Analistin dokümanda bulduğu hata ile testin yakaladığı hata aynı Jira kaydında buluşur.

PR ve merge

Yerel kontrolleri geçen her case kendi dalını ve PR’ını alır; PR’ı GitHub App gibi bir bot kimliği açar. Bot PR açar ama asla merge etmez.

PR açıklaması izlenebilirlik bilgisi taşır:

• Story, case ve onaylayan kişi.
• Onaylanan içerik hash’i ve denetim zincirinin başı.
• Adım eşlemesi ve yerel kontrol sonuçları.
• Yapay zekâ (AI) çıktısı REPLAY kaydından geldiyse bunu belirten not.

Değişen tek dosya üretilen testtir. Merge için korumalı dalın zorunlu kontrollerinin yeşil olması ve bir insan onayı gerekir. Portal merge kapısını gösterir ve önündeki engelleri listeler: kırmızı kontrol, main’in gerisinde kalmış dal ya da hâlâ süren Kırarak Doğrula (Break-to-Verify) gibi. Merge’den sonra diğer açık bot dalları yeni main’e taşınır ve bir push koşusu main’i tam paketle doğrular.

Masaüstü, mobil ve Selenium (Yol haritası)

Aşağıdakiler bugün üründe yoktur:

• Masaüstü (FlaUI) ve mobil (Appium) kod üretimi (Yol haritası). Tarih pilot talebiyle belirlenir. Antrek Labs masaüstü ve mobil test otomasyonunu bugün hizmet olarak sunar.
• Selenium’dan Playwright’a göç (Yol haritası). Ürün yeni Playwright testleri üretir; mevcut Selenium suite’lerini dönüştürmez. Göç bugün Antrek Labs hizmeti olarak sunulur.

Gereksinim ön incelemesi ve test case üretimi uygulamanın teknolojisinden bağımsızdır, ancak henüz bir mobil ya da masaüstü pilotunda doğrulanmamıştır. Bu yetenekler sizin için önemliyse pilot görüşmesinde dile getirin; pilot koşulu olarak tanımlanabilsinler.