🤖 UI Otomasyonu: Selenium & Playwright

UI Otomasyonu: Selenium & Playwright: Claude'dan yapıştırılan bir HTML parçasından locator ürettirmek, bir çilingirden kilidin kendisi yerine bir FOTOĞRAFINDAN anahtar kesmesini

Claude'dan yapıştırılan bir HTML parçasından locator ürettirmek, bir çilingirden kilidin kendisi yerine bir FOTOĞRAFINDAN anahtar kesmesini istemeye benzer — mekanizma birebirdir: bir fotoğraf (statik bir HTML parçası) kilidin şeklini o anki haliyle gösterir, ama gerçek kilit (canlı DOM) sayfa bir sonraki render'da hafifçe farklı bir anahtar deliğine sahipse (yeniden sıralanmış bir class listesi, dinamik üretilmiş bir id), kesilen anahtar (üretilen locator) uymayabilir. Üzerinde durulmaya değer soru şu: Claude senin parçandan çalışan bir XPath ürettiyse, ÖZELLİK'te hiçbir şey değişmediği halde bu neden bir sonraki deploy'da kırılıyor? Çünkü kırılgan bir locator (derin bir XPath pozisyonu, framework'ün ürettiği bir class hash'i) DOM'un tesadüfi yapısını kodlar, geliştiricinin niyetini değil — ve sadece dondurulmuş bir HTML anlık görüntüsüyle çalışan Claude, hangi niteliklerin KARARLI (QA'nın sahip olduğu bir data-testid) hangilerinin TESADÜFİ (bir CSS-modül hash'i) olduğunu, ona öncelik vermesini söylemedikçe bilemez. Java karşılaştırması: bu, bir private field'a tam bildirim sırasına göre bir reflection çağrısını gömmekle aynı kırılganlık sınıfındadır — bugün derlenir ve çalışır ama aslında güvendiğin kontrat hiçbir zaman bir garanti değildi. QA tarafındaki bedel: ilgisiz her frontend refactor'ünde sessizce kıran, Claude'un ürettiği XPath locator'larla dolu bir CI seti, yerini aldığı elle yazılmış locator'lardan bakımı daha yavaştır — düzeltme, Claude'a data-testid'e öncelik vermesini prompt'lamaktır, ilk ürettiği selector'ı kabul etmek değil.

HTML Parçasından Refactor'e Dayanıklı Bir Locator'a

Gerçek HTML elementini yapıştır (bir açıklamasını değil) ve Claude'a pozisyonel/yapısal selector'lar (nth-child, derin XPath) yerine kararlı bir niteliğe (data-testid, aria-label, bir role) öncelik vermesini açıkça söyle. Yapıştırılan HTML'de kararlı bir nitelik yoksa, Claude'dan bu boşluğu sessizce kırılgan bir fallback uydurmak yerine açıkça bildirmesini iste.

Akıl yürütme: neden tek seferlik locator'lar yerine tam bir Page Object Model iskeleti üretilsin? Bir POM, yukarıdaki kırılganlık riskini tam olarak sayfa başına TEK bir dosyada merkezileştirir — bir locator kırılırsa, onu satır içinde tekrarlayan her testi aramak yerine tek bir yerde düzeltirsin. Claude, sayfanın HTML'ini ve ihtiyacın olan eylemleri verdiğinde MEKANİK iskelette (sınıf yapısı, constructor, kullanıcı eylemlerini yansıtan metod isimleri) iyidir — ama içindeki gerçek selector DİZİLERİ, tıpkı bir önceki noktadaki gibi, hâlâ senin kararlılık incelemene ihtiyaç duyar.

Page Object Model: Java Selenium ve TypeScript Playwright

By.cssSelector("[data-testid=...]") Neden Konum/XPath'ten Daha Dayanıklı?

By.cssSelector("[data-testid='login-email']") ifadesi…

By.cssSelector("[data-testid='login-email']") ifadesi, elementi DOM'daki KONUMUNA göre değil, geliştiricinin BİLEREK eklediği bir data-testid ATTRIBUTE'üne göre bulur — bu attribute SADECE test amaçlı vardır, hiçbir CSS/JS mantığı ona BAĞLI değildir.

Bir frontend refactor'ü elementin YERİNİ…

Bir frontend refactor'ü elementin DOM ağacındaki YERİNİ (kaçıncı sıradaki div olduğunu) veya class isimlerini (CSS-module hash) SIK SIK değiştirir — ama data-testid gibi bir kontrat, ekip bunu BİLEREK bozmadıkça SABİT kalır.

Constructor'da driver referansı SAKLANIR…

Constructor'da driver referansı SAKLANIR (private WebDriver driver), böylece login() metodu her çağrıldığında AYNI driver session'ı üzerinden elementleri ARAR — yeni bir bağlantı AÇILMAZ.

login(email, password) metodu, 3 findElement + sendKeys/click çağrısını TEK bir okunabilir işlem haline GETİRİR — testin kendisi artık "hangi CSS selector" ile değil, "login yap" diye KONUŞUR.