Test otomasyonunun doğuşu
Web tarayıcısının doğduğu 1990'lara geri dönelim. Tarayıcılar arası ve birden çok cihazda test etmeyle ilgili zorlukların üstesinden gelmek için Selenium ve WebDriver projelerinin ortaya çıkmasıyla birlikte test otomasyonu 2000'lere kadar ortaya çıkmadı.
Bu iki proje, 2011'de Selenium WebDriver olarak güçlerini birleştirdi ve 2018'de W3C standardı haline geldi. Genellikle WebDriver veya WebDriver "Klasik" olarak adlandırılır.
WebDriver "Klasik" sürümünden önce test otomasyonu oldukça karmaşıktı. Tarayıcı testini otomatikleştirebilmek geliştiricilerin ve test kullanıcılarının hayatlarının kalitesini önemli ölçüde artırdı.
JavaScript'in yükselişi
Web geliştirme süreci JavaScript'i temel alacak şekilde geliştikçe WebdriverIO, Appium, Nightwatch, Protractor (kullanımdan kaldırıldı), Testcafe, Cypress, Puppeteer ve Playwright gibi yeni otomasyon çözümleri ortaya çıktı.
Otomasyon yaklaşımları
Genel olarak bu araçlar, tarayıcıları otomatikleştirmelerine bağlı olarak iki ana gruba ayrılabilir:
- Yüksek düzey: Tarayıcı içinde JavaScript'i yürüten araçlar. Örneğin Cypress ve TestCafe, testleri doğrudan tarayıcıda çalıştırmak için web API'leri ve Node.js'den yararlanır. İşin eğlenceli yanı, Selenium'un ilk sürümünde de aynı yaklaşım kullanılıyordu.
- Düşük düzeyli: Tarayıcı dışında uzak komutları yürüten araçlar. Araçlar birden fazla sekme açma veya cihaz modunu simüle etme gibi daha da fazla kontrol gerektirdiğinde, tarayıcıyı protokoller aracılığıyla kontrol etmek için uzaktan komutlar yürütmeleri gerekir. İki temel otomasyon protokolü, WebDriver "Klasik" ve Chrome DevTools Protocol (CDP)'dir.
Bir sonraki bölümde, güçlü yanlarını ve sınırlamalarını anlamak için bu iki protokolü inceleyeceğiz.
WebDriver "Klasik" ve Chrome Geliştirici Araçları Protokolü (CDP) karşılaştırması
WebDriver "Klasik", tüm önemli tarayıcılar tarafından desteklenen bir web standardıdır. Otomasyon komut dosyaları, HTTP istekleri aracılığıyla bir sürücü sunucusuna komutlar yayınlar. Sürücü sunucusu da dahili, tarayıcıya özel protokoller üzerinden tarayıcılarla iletişim kurar.
Tarayıcılar arası mükemmel destek ve API'leri test için tasarlanmış olsa da yavaş çalışabilir ve bazı alt düzey kontrolleri desteklemez.
Örneğin, await coffee.click(); öğesini tıklayan bir test komut dosyanız olduğunu düşünün. Bu istek, bir dizi HTTP isteğine dönüştürülür.
# WebDriver: Click on a coffee element
curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
-H 'Content-Type: application/json'
-d '{}'
Öte yandan, Chrome Geliştirici Araçları Protokolü (CDP) başlangıçta Chrome Geliştirici Araçları ve hata ayıklama için tasarlanmış olsa da otomasyon için Puppeteer tarafından benimsenmiştir. CDP, WebSocket bağlantıları üzerinden doğrudan Chromium tabanlı tarayıcılarla iletişim kurarak daha hızlı performans ve alt düzey denetim sağlar.
Ancak, yalnızca Chromium tabanlı tarayıcılarla çalışır ve açık bir standart değildir. Üstelik CDP API'leri nispeten karmaşıktır. Bazı durumlarda, CDP ile çalışmak ergonomik değildir. Örneğin, işlem dışı iframe'lerle çalışmak çok fazla çaba gerektirir.
Örneğin, await coffee.click(); adlı bir öğenin tıklanması, bir dizi CDP komutuna dönüştürülür.
// CDP: Click on a coffee element
// Mouse pressed
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}
// Mouse released
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}
Alt düzey kontroller nelerdir?
WebDriver “Klasik”in geliştirildiği günlerde, alt düzey denetime ihtiyaç yoktu. Ancak zaman değişti, artık web çok daha yetenekli ve günümüzde test etmek daha titiz davranmayı gerektiriyor.
CDP tüm hata ayıklama ihtiyaçlarını karşılayacak şekilde tasarlandığından, "Klasik" WebDriver'a kıyasla daha düşük düzeyli kontrolleri destekler. Aşağıdaki gibi özellikleri işleyebilir:
- Konsol mesajlarını yakalama
- Ağ isteklerine müdahale etme
- Cihaz modu simülasyonu
- Coğrafi konum simülasyonu
- Diğer ölçütler
Farklı mimariden dolayı “Klasik” WebDriver’da bunlar mümkün değildi; WebDriver “Klasik” ise HTTP tabanlıdır ve tarayıcı etkinliklerine abone olmayı ve dinlemeyi zorlaştırır. Öte yandan CDP, WebSocket tabanlıdır ve varsayılan olarak çift yönlü mesajlaşmayı destekler.
Sıradaki adım: WebDriver BiDi
Aşağıda, "Klasik" WebDriver ve CDP'nin güçlü yanlarının bir özeti verilmiştir:
| WebDriver “Klasik” | Chrome Geliştirici Araçları Protokolü (CDP) |
|---|---|
| Tarayıcılar arası en iyi destek | Hızlı, çift yönlü mesajlaşma |
| W3C standardı | Alt düzey kontrol sağlar |
| Test için geliştirildi |
WebDriver BiDi, WebDriver "Klasik" ve CDP'nin en iyi yönlerini birleştirmeyi amaçlar. Bu, şu anda geliştirilmekte olan yeni bir standart tarayıcı otomasyon protokolüdür.
WebDriver BiDi projesi (nasıl çalıştığı, vizyonu ve standartlaştırma süreci) hakkında daha fazla bilgi edinin.