# Test Otomasyonunda Mimari Evrim

UI test otomasyonunda son yıllardaki değişimi sadece “Selenium mu, Playwright mı?” tartışmasıyla açıklamak eksik kalıyor. Asıl fark, test kodunun tarayıcıyla nasıl konuştuğunda ortaya çıkıyor. Protokol seviyesi değiştikçe hız, gözlemlenebilirlik, bekleme stratejileri ve bakım maliyeti de değişiyor.

— -

1. WebDriver Classic: Standartlaşmış Ama Sınırlı Model

Uzun süre tarayıcı otomasyonunun ana modeli WebDriver Classic oldu. Test kodu ChromeDriver, GeckoDriver veya benzeri bir driver’a HTTP üzerinden komut gönderir; driver bu komutu tarayıcıya iletir ve cevap dönerdi.

Bu modelin en büyük avantajı standartlaşmış ve tarayıcılar arası çalışabilir olmasıydı. Dezavantajı ise iletişimin çoğunlukla request/response yapısında kalmasıydı. Tarayıcı içinde olan biteni olay bazlı takip etmek, network trafiğine müdahale etmek, console loglarını anlık yakalamak veya sayfa davranışına daha yakın senkronizasyon kurmak her zaman kolay değildi.

Buna bir de tarayıcı, driver ve framework sürümleri arasındaki uyum ihtiyacı eklenince, özellikle büyük test paketlerinde bakım maliyeti artıyordu.

— -

2. CDP ve Modern Browser Automation Yaklaşımı

Puppeteer ve Playwright gibi araçlar, WebDriver Classic’in sınırlarını aşmak için tarayıcıya daha düşük seviyeden yaklaşan bir model kullandı. Chromium tarafında bunun temel yapı taşlarından biri Chrome DevTools Protocol, yani CDP oldu.

Burada küçük ama önemli bir ayrımı not etmek gerekiyor: Playwright, CDP’yi doğrudan kullanmak yerine kendi iç protokol katmanıyla soyutluyor. Bu yüzden Puppeteer ile aynı kefeye koymak biraz yanıltıcı olabilir; Playwright’ın sağladığı kararlılığın bir kısmı da bu soyutlama katmanından geliyor.

CDP sayesinde network istekleri, console çıktıları, performans metrikleri, tracing, coverage ve benzeri tarayıcı içi sinyallere daha doğrudan erişmek mümkün hale geldi. Bu da sadece “elemente tıkla, sonucu bekle” seviyesinden çıkıp tarayıcı davranışını daha yakından yöneten test mimarilerine kapı açtı.

Bu dönemde önemli değişimlerden biri, testte kullanılan tarayıcı binary’lerinin daha kontrollü yönetilmesiydi. Chrome for Testing, otomasyon senaryoları için sürümlenebilir ve otomatik güncellenmeyen Chrome binary’leri sunarak Chrome/ChromeDriver uyumsuzluğu gibi problemleri azaltıyor ve Selenium dahil Chrome tabanlı otomasyon yapan herkesin kullanabileceği sürümlenebilir bir Chrome dağıtımıdır. Asıl faydası; CI ortamında Chrome ve ChromeDriver sürümlerini kontrol altına alarak test koşularını daha tekrarlanabilir hale getirmesidir.

Playwright ise varsayılan olarak kendi sürümüne bağlı Chromium, Firefox ve WebKit binary’lerini yönetiyor; Playwright sürümü güncellendiğinde ilgili browser binary’lerinin de playwright install ile güncellenmesi gerekebiliyor. Ortak fikir aynı: CI ortamında hangi tarayıcı sürümüyle test koştuğunu bilmek, test sonuçlarını daha tekrarlanabilir ve debug edilebilir hale getiriyor.

— -

3. WebDriver BiDi: Standart Tarafa Geri Dönüş

CDP güçlü bir protokol, ancak Chrome/Chromium merkezli. Firefox, Safari ve diğer tarayıcılar açısından kalıcı çözüm, tarayıcılar arası ortak bir otomasyon standardının gelişmesi.

WebDriver BiDi bu noktada devreye giriyor. BiDi, klasik WebDriver’daki tek yönlü komut/cevap modelinin ötesine geçerek WebSocket tabanlı, çift yönlü iletişim sağlıyor. Böylece tarayıcıdan otomasyon aracına event akışı mümkün oluyor: console logları, network olayları, script eventleri ve benzeri sinyaller daha doğal şekilde takip edilebiliyor.

Buradaki kritik fark şu: CDP pratikte çok güçlü bir Chromium protokolüyken, WebDriver BiDi tarayıcı üreticilerinin üzerinde uzlaştığı standart bir zemin oluşturmayı hedefliyor. Ancak “standart üzerinde uzlaşıldı” demek “tam destek sağlandı” anlamına gelmiyor. Safari’nin BiDi desteği hâlâ çekingen seyrediyor; bu da cross-browser iddiasının gerçek tarayıcı davranışına ne kadar yakın olduğunu test etmeyi gerekli kılıyor. Selenium ekibi de CDP’ye dayanan geçici kabiliyetleri zaman içinde BiDi ile karşılamayı hedefliyor.

4. Mimari Açıdan Bizi Ne Bekliyor?

Kısa vadede tek bir protokolün her şeyi çözmesini beklemek gerçekçi değil. Daha olası senaryo, araçların hibrit çalışması: Chromium tarafında CDP veya CDP’den türeyen mekanizmalar, standartlaşan alanlarda ise WebDriver BiDi.

Test mühendisinin günlük kodunda bu fark çoğu zaman görünmeyecek. Yine page.click(), locator.fill() veya benzeri API’lerle çalışacağız. Ancak bu API’lerin altında hangi protokolün çalıştığı; stabiliteyi, debug kabiliyetini, cross-browser desteğini ve CI’daki bakım maliyetini doğrudan etkiliyor.

Bu yüzden araç seçimini salt “hangi framework daha popüler?” sorusuna indirgemek riskli. Browser sürümleri nasıl yönetiliyor, network ve console sinyalleri ne kadar erişilebilir, cross-browser destek gerçek tarayıcı davranışına ne kadar yakın, protokol bağımlılığı uzun vadede bakım riski yaratıyor mu — bunlar, popülerlik sıralamasından çok daha belirleyici sorular.

Modern web otomasyon mimarisi artık sadece test yazma kolaylığıyla değil, tarayıcıyla kurduğu iletişim modelinin sağlamlığıyla değerlendirilmeli. Çünkü flaky testlerin önemli bir kısmı assertion satırında değil, tarayıcıyla kurduğumuz mimari ilişkinin zayıf olduğu yerde başlıyor — ve bunu genellikle en kötü zamanda, prod pipeline’ı kilitlenince fark ediyoruz.

— -

#TestAutomation #SoftwareEngineering #Playwright #Selenium #WebDriverBiDi #QAArchitecture #SoftwareTesting