Playwright CLI Nedir? Claude Code ile Chrome’u Daha Az Token Kullanarak Kontrol Edin

AI kodlama asistanları uzun süre tek bir işi yaptı: kod yazmak. Bugünün coding agent‘ları ise bunun ötesine geçti — bir web sitesini açabiliyor, sayfalar arasında gezinebiliyor, butona tıklayabiliyor, form doldurabiliyor, uygulamayı inceleyebiliyor, test edebiliyor, ekran görüntüsü alabiliyor ve yaptığı frontend değişikliğini tarayıcıda kendisi doğrulayabiliyor.

Bu yeteneğin bir maliyeti var: tarayıcının durumu modele geri gönderilmek zorunda. Ekran görüntüleri, DOM parçaları, erişilebilirlik ağaçları ve araç tanımları hızla birikir — ve bunların hepsi, modelin üzerinde çalıştığı proje koduyla aynı sınırlı alanı, yani context window‘u paylaşır.

Microsoft’un Playwright CLI‘si tam bu soruna yönelik tasarlanmış. Resmî dokümantasyondaki tanımıyla: “coding agent’lar için tasarlanmış bir browser automation komut satırı arayüzü” ve amacı “kısa CLI komutları ve kurulabilir skill’ler aracılığıyla token verimli tarayıcı kontrolü” sağlamak.

Bu yazıda Playwright CLI’nin ne olduğunu, neden daha az bağlam tükettiğini, Claude Code ile nasıl birlikte çalıştığını ve bir WordPress geliştiricisinin bunu günlük işine nasıl katabileceğini anlatıyorum. Buradaki her komut ve gereksinim resmî Playwright dokümantasyonundan doğrulandı; kaynaklar yazının sonunda. Uydurma sayı, uydurma komut ve doğrulanmamış yüzde iddiası yok.

Playwright nedir?

Playwright, Microsoft tarafından geliştirilen açık kaynaklı bir browser automation ve end-to-end test aracı. En sade tanımıyla: bir tarayıcıyı insan gibi kullanabilen, ama bunu kod üzerinden yapan bir kütüphane. Sayfayı açar, elemanı bulur, tıklar, yazar, sonucu kontrol eder.

Resmî dokümantasyona göre Playwright üç tarayıcı motorunu destekliyor:

• Chromium — açık kaynak sürümlerin yanı sıra markalı kanallar: chrome, msedge ve bunların beta/dev/canary varyantları. Yani gerçek Google Chrome ve Microsoft Edge ile de test edilebiliyor.
• Firefox — güncel Firefox Stable sürümüyle eşleşen bir yapı.
• WebKit — Safari’nin arkasındaki motorun güncel kaynaklarından türetilmiş bir yapı.

Küçük ama önemli bir ayrıntı: Playwright markalı Safari ile çalışmıyor — çünkü Safari’nin kamuya açık sürümünde bulunmayan yamalara ihtiyaç duyuyor. WebKit motoru üzerinden test edebilirsiniz, ama bu birebir Safari değildir.

End-to-end test kavramı da şu demek: uygulamayı parçalara ayırıp tek tek fonksiyon test etmek yerine, gerçek bir kullanıcının yaptığı yolu baştan sona yürümek. “Ana sayfayı aç → menüye tıkla → iletişim formunu doldur → gönder → teşekkür mesajını gör.” Bu yol çalışıyorsa uygulama gerçekten çalışıyordur.

Playwright CLI nedir?

Playwright CLI, Playwright’ın coding agent’lar için hazırlanmış komut satırı arayüzü. Normal Playwright’ta test yazarsınız — dosya açar, kod yazar, çalıştırırsınız. Playwright CLI’de ise agent doğrudan terminale kısa komutlar yazar ve tarayıcı anında tepki verir.

Resmî hızlı başlangıç rehberindeki temel döngü dört adım:

1. Open — playwright-cli open bir adresi açar.
2. Snapshot — her komut, element ref’leriyle birlikte erişilebilirlik ağacını döndürür.
3. Interact — bu ref’ler kullanılarak tıklanır, yazılır, doldurulur.
4. Re-snapshot — her eylem, yeni ref’lerle güncellenmiş durumu geri verir.

Dokümantasyondaki örnek akış aynen şöyle görünüyor:

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli check e21
playwright-cli screenshot

Buradaki e21 bir ref — yani snapshot içinde o elemana verilmiş kısa bir kimlik. Agent “sayfanın sol üstündeki üçüncü onay kutusu” gibi belirsiz bir tarif yapmıyor; doğrudan e21 diyor. Bu hem kesin hem de kısa.

Resmî skill dosyasında komutlar şu gruplar altında toplanıyor: Core (open, goto, click, type, fill, drag, drop), Navigation (go-back, go-forward, reload), Keyboard (press, keydown, keyup), Mouse, Save as (screenshot, pdf), Tabs (tab-list, tab-new, tab-close, tab-select), Storage (cookie, localStorage, sessionStorage), Network (route, unroute) ve DevTools (console, requests, tracing, video).

Dokümantasyonda öne çıkarılan diğer özellikler: daemon mimarisi (tarayıcı süreci ayakta kalır, her komutta yeniden başlatma maliyeti yoktur), ref tabanlı etkileşim, skill sistemi, çoklu tarayıcı desteği (Chrome, Firefox, WebKit, Edge) ve oturum yönetimi (birbirinden yalıtılmış birden fazla tarayıcı örneği).

Playwright CLI neden daha az token kullanabiliyor?

Bu yazının çekirdek bölümü. Önce kavramı netleştirelim.

Context window nedir?

Bir dil modelinin aynı anda “aklında tutabildiği” metin miktarı sınırlıdır. Buna context window denir ve token cinsinden ölçülür. Bu alanın içine şunların hepsi girmek zorundadır: sistem talimatları, proje dosyaları, kaynak kod, konuşma geçmişi, araç tanımları ve — tarayıcı kullanılıyorsa — tarayıcıdan gelen her şey.

Yani bu bir rekabet. Tarayıcı durumu ne kadar yer kaplarsa, gerçek işiniz olan koda o kadar az yer kalır.

Klasik browser agent akışı

Claude
   ↓
Browser aracı (tool)
   ↓
Büyük tarayıcı durumu
   (ekran görüntüsü / DOM / erişilebilirlik ağacı / araç şemaları)
   ↓
Claude durumu analiz eder
   ↓
Eylem
   ↓
Yine büyük tarayıcı durumu…

Her turda benzer büyüklükte bir yük geri geliyor. Beş adımlık basit bir kontrol bile ciddi bir birikim yaratabiliyor.

Playwright CLI akışı

Claude Code
   ↓
Kısa playwright-cli komutu
   ↓
Tarayıcı eylemi
   ↓
Kompakt sonuç / snapshot (ref'lerle)
   ↓
Sonraki komut

Fark nerede? Resmî dokümantasyonun ifadesiyle CLI komutları “büyük araç şemalarını ve ayrıntılı erişilebilirlik ağaçlarını model bağlamına yüklemekten kaçınır“. Snapshot dokümantasyonu da bunu somutlaştırıyor: snapshot ekran görüntülerinden küçüktür (piksel değil, yapılandırılmış metin), tam DOM’dan küçüktür (ham HTML değil, yalnızca etkileşimli elemanlar) ve makine tarafından okunması kolaydır.

Resmî dokümantasyondaki örnek snapshot çıktısı şöyle görünüyor — bir ekran görüntüsünün yanında ne kadar küçük olduğunu görmek için yeterli:

- heading "todos" [level=1]
- textbox "What needs to be done?" [ref=e5]
- listitem:
  - checkbox "Toggle Todo" [ref=e10]
  - text: "Buy groceries"

Burada net olmak istiyorum: Microsoft’un dokümantasyonu Playwright CLI’yi coding agent’lar için “token verimli” bir seçenek olarak tanımlıyor, ancak resmî kaynaklarda “%X daha az token” gibi bir ölçüm yayınlanmış değil. Bu yüzden bu yazıda hiçbir yüzde vermiyorum. Gerçek kazanç; sitenin karmaşıklığına, kaç adım attığınıza, kaç ekran görüntüsü aldığınıza ve karşılaştırdığınız alternatife göre değişir.

Playwright CLI ve Playwright MCP karşılaştırması

Playwright’ın bir de MCP (Model Context Protocol) sunucusu var. İkisi rakip değil; farklı problemleri çözüyorlar.

Resmî dokümantasyon bu ayrımı şöyle yapıyor: playwright-cli “token verimli, skill tabanlı akışları tercih eden coding agent’lar için en uygunu”; MCP ise “kalıcı durum ve yinelemeli akıl yürütme gerektiren özelleşmiş agentic loop’lar” için uygun.

MCP “kötü” değil. Bunu net söylemek gerekiyor, çünkü “CLI daha az token kullanıyor” cümlesi kolayca “o zaman MCP gereksiz” diye yanlış anlaşılıyor. Kod yazarken arada bir siteyi kontrol ediyorsanız CLI daha rahat. Uzun soluklu, tarayıcı üzerinde kalıcı durum tutan otonom bir akış kuruyorsanız MCP’nin sunduğu yapı işinize yarayabilir.

Playwright Skills nedir?

Resmî tanımıyla skill’ler, “coding agent’lara playwright-cli‘yi etkili şekilde kullanmayı öğreten, agent’ın keşfedip kullanabileceği yapılandırılmış referans dokümantasyonu”.

Kurulum komutu:

playwright-cli install --skills

Dokümantasyona göre skill’ler Claude Code, GitHub Copilot, Cursor ve “yerel olarak kurulan skill’leri destekleyen herhangi bir coding agent” ile çalışıyor.

Claude Code
   ↓
Playwright Skill (yerel referans dokümantasyonu)
   ↓
Hangi playwright-cli akışının mevcut olduğunu bilir
   ↓
Tarayıcı eylemlerini çalıştırır

Skill paketinin kapsadığı konular arasında şunlar var: Playwright testlerini çalıştırma ve hata ayıklama, istek mocklama, Playwright script’leri çalıştırma, tarayıcı oturumlarını yönetme, tarayıcı durumunu (çerez, localStorage) kalıcı hale getirme, etkileşimlerden test üretme, trace kaydetme, video kaydı ve snapshot’ta görünmeyen element özniteliklerini inceleme.

Beklentiyi doğru kurmak adına: skill sihir değil, dokümantasyon. Agent’a yeni bir yetenek eklemiyor; var olan yeteneği nasıl kullanacağını öğretiyor. Nitekim dokümantasyon, skill kurmadan da agent’ın komutları playwright-cli --help ile keşfedebileceğini söylüyor.

Kurulum

Gereksinimler

Resmî kurulum sayfasına göre iki şey gerekiyor:

• Node.js 20 veya daha yenisi
• Bir coding agent — dokümantasyonun ifadesiyle “Claude Code, GitHub Copilot veya benzeri”

Playwright CLI kurulumu

npm install -g @playwright/cli@latest
playwright-cli --help

Global kurmak istemiyorsanız npx ile de çalıştırabilirsiniz:

npx playwright-cli --help

Projeye bağımlılık olarak eklemek isterseniz: npm install -D @playwright/cli@latest

Skill kurulumu

playwright-cli install --skills

Tarayıcı kurulumu

Dokümantasyon, CLI’nin ilk kullanımda tarayıcıyı otomatik indirdiğini belirtiyor — yani bu adım isteğe bağlı. Yine de elle kurmak isterseniz:

playwright-cli install-browser               # varsayılan (chromium)
playwright-cli install-browser firefox       # belirli bir tarayıcı
playwright-cli install-browser --with-deps   # sistem bağımlılıklarıyla

Kurulumu doğrulamak için resmî yöntem playwright-cli --help. Dokümantasyonda geçmeyen ek kurulum adımı uydurmuyorum.

Chrome’u Playwright CLI ile kullanmak

Varsayılan olarak tarayıcı arka planda (headless) çalışır. Ne olup bittiğini gözünüzle görmek istiyorsanız --headed kullanılır:

playwright-cli open https://example.com --headed

Tarayıcı seçimi de mümkün. Deponun README’sinde belgelenen yöntem --browser parametresi:

playwright-cli open https://example.com --headed --browser=chrome

Burada chrome, Chromium’un açık kaynak yapısı yerine sistemde kurulu gerçek Google Chrome anlamına geliyor. Bu, “Chrome’da farklı görünüyor” tipi sorunları kovalarken önemli bir fark.

Claude mevcut Chrome oturumumu kontrol edebilir mi?

Evet — ama bu, yazının en dikkatli okunması gereken kısmı.

Playwright CLI, yeni bir tarayıcı başlatmak yerine var olan bir tarayıcıya bağlanabiliyor. Deponun README’sinde ve skill dosyasında belgelenen komutlar:

playwright-cli attach --extension=chrome
playwright-cli attach --cdp=chrome
playwright-cli attach --cdp=msedge
playwright-cli attach --cdp=http://localhost:9222

Uzantı yolu için Playwright’ın kendi tarayıcı uzantısı kullanılıyor. Playwright dokümantasyonunun uzantı sayfasına göre bu uzantı, “mevcut tarayıcı sekmelerine bağlanmayı” sağlıyor ve böylece “yeni bir tarayıcı örneği başlatmak yerine oturum açmış oturumlarınızı, çerezlerinizi ve kurulu uzantılarınızı yeniden kullanabiliyorsunuz”. Dokümantasyonun saydığı tipik kullanım senaryoları: SSO/2FA gerektiren girişleri tekrar tekrar yapmamak, uzantıya bağımlı sayfalarla çalışmak ve zaten açık olan sekmeleri otomatikleştirmek.

İki senaryo arasındaki fark şu:

• Yeni, yalıtılmış tarayıcı — boş bir profil. Hiçbir yere giriş yapılmamış, çerez yok, geçmiş yok. Bir şey ters giderse etki alanı o pencereyle sınırlı.
• Mevcut, oturum açılmış Chrome — sizin günlük tarayıcınız. WordPress admin’iniz, hosting paneliniz, e-postanız, bankacılığınız, sosyal medyanız… hepsi zaten açık.

İkincisi çok pratiktir ve tam olarak bu yüzden risklidir. AI’ya oturum açılmış bir tarayıcı vermek, ona o tarayıcının ulaşabildiği her şeye ulaşma imkânı vermektir. Bunu yapacaksanız bilinçli yapın: gereksiz sekmeleri kapatın, ayrı bir Chrome profili kullanın ve kritik hesaplarınızın o profilde açık olmamasına dikkat edin.

Claude Code + Playwright mimarisi

Claude Code
   ↓
Playwright Skills
   ↓
Playwright CLI
   ↓
Chrome
   ↓
Web sitesi / WordPress

Katmanları tek tek okuyalım:

• Claude Code — akıl yürüten katman. “Ne yapmalıyım, bu sonuç ne anlama geliyor, sırada ne var” sorularını yanıtlar. Kodu da o yazar.
• Playwright Skills — Claude’a hangi komutların var olduğunu ve nasıl kullanılacağını anlatan yerel referans.
• Playwright CLI — komutu alıp tarayıcıya çeviren ve geriye kompakt snapshot döndüren katman.
• Chrome — gerçek tarayıcı. Sayfa gerçekten render edilir, JavaScript gerçekten çalışır.
• Web sitesi / WordPress — test edilen hedef.

Dikkat: Claude burada siteye “saldıran” bir uygulama değil, komutu seçen katman. Hangi siteye yöneltileceğine ve neye izin verileceğine siz karar veriyorsunuz.

WordPress örneği

Bir WordPress geliştiricisi için en somut fayda burada. Diyelim ki Claude Code’a şunu söylüyorsunuz:

Staging WordPress sitemi aç ve ana sayfanın, navigasyon menüsünün, iletişim formunun ve responsive yerleşimin doğru çalıştığını doğrula.

Claude Code
   ↓
Playwright CLI
   ↓
Chrome
   ↓
WordPress staging sitesi
   ↓
Sayfalar test edilir
   ↓
Sorun bulunur
   ↓
Geliştirici sonucu inceler

Asıl güçlü olan ikinci döngü — kod ile tarayıcı arasındaki geri besleme:

Claude kodu değiştirir
   ↓
Playwright siteyi açar
   ↓
Frontend'i kontrol eder
   ↓
Ekran görüntüsü alır
   ↓
Sorunu tespit eder
   ↓
Claude kodu düzeltir
   ↓
Playwright yeniden test eder

Bu döngünün değeri şurada: WordPress’te bir CSS değişikliğinin gerçekten ne yaptığını ancak tarayıcıda görürsünüz. Tema, eklentiler, Elementor çıktısı ve önbellek katmanları üst üste bindiğinde “kodda doğru görünüyor” ile “sitede doğru görünüyor” iki ayrı şeydir. Agent’ın kendi değişikliğini kendi gözüyle doğrulayabilmesi, bu boşluğu kapatır.

Yapay zekâyı iş akışına katmaya yeni başlıyorsanız Claude’a ilk adım: yeni başlayanlar için başlangıç rehberi yazımız iyi bir başlangıç noktası.

Elementor kullananlar için

Elementor ile çalışan bir geliştirici için bu akış özellikle frontend doğrulama tarafında işe yarar:

• Elementor ile üretilmiş sayfaları açmak ve render edilmiş frontend’i kontrol etmek
• Sayfalar arasında gezinmek, butonların gerçekten çalıştığını görmek
• Formları test etmek, bağlantıların kırık olup olmadığını kontrol etmek
• Yerleşim değişikliklerinden sonra ekran görüntüsü alıp öncesi/sonrası karşılaştırmak
• Özel HTML veya CSS ekledikten sonra sonucun bozulup bozulmadığını doğrulamak

Gerçekçi olalım: Elementor’un düzenleyici arayüzü ağır JavaScript’e, iç içe iframe’lere ve sürükle-bırak etkileşimlerine dayanıyor. Bir agent’ın düzenleyici içinde her sürükle-bırak işlemini güvenilir biçimde yapacağını iddia etmiyorum — bu tür arayüzler otomasyon için zordur ve kırılgandır. Bu akışın güçlü olduğu yer düzenleyicinin içi değil, yayınlanmış sayfanın frontend’i. Orada Playwright çok rahat çalışır.

Web sitesi test örneği

Somut, güvenli ve tekrarlanabilir bir görev örneği. Kontrol listesi:

• Ana sayfa hatasız yükleniyor mu?
• Navigasyon menüsündeki bağlantılar doğru sayfalara gidiyor mu?
• “İletişim” butonu çalışıyor mu?
• İletişim formu sayfada var mı ve alanları görünüyor mu?
• Dar ekranda mobil menü ortaya çıkıyor mu?
• Gizlilik politikası sayfası açılıyor mu?
• Konsolda JavaScript hatası var mı? (playwright-cli console)

Claude
   ↓
Playwright
   ↓
Testi çalıştırır
   ↓
Rapor sunar

Bu listedeki her madde okuma ve doğrulama işlemi — hiçbiri veri değiştirmiyor, hiçbiri geri alınamaz değil. Bu tür bir kontrol listesi, her yayın öncesi çalıştırılabilecek en ucuz güvenlik ağıdır. Not: form varlığını kontrol etmek ile formu gerçek veriyle göndermek farklı şeylerdir; ikincisi onay gerektiren bir işlem olmalı.

Bu neden AI geliştiricileri için ilginç?

Eskiden döngü şöyleydi:

Geliştirici → kod yazar → tarayıcıyı elle açar
→ elle test eder → koda geri döner

Şimdi mümkün olan:

Geliştirici
   ↓
Claude Code
   ↓
Kodu yazar
   ↓
Playwright test eder
   ↓
Claude sonucu inceler
   ↓
Kodu düzeltir
   ↓
Playwright yeniden test eder

Buradaki asıl kazanım hız değil, kapalı döngü. Bir agent kendi çıktısını doğrulayabildiğinde, “yazdım, umarım çalışır” ile “yazdım, çalıştığını gördüm” arasındaki farkı kapatır. Yine de döngünün başında ve sonunda insan durmalı: neyin test edileceğine ve neyin yayına gideceğine karar veren taraf hâlâ siz olmalısınız.

Token verimliliği neden önemli?

Bu konu “maliyet” meselesinden ibaret değil. Asıl mesele yer.

Modelin context window’u içinde şunlar aynı alan için yarışır:

• proje dosyaları ve kaynak kod
• sizin talimatlarınız ve proje kuralları
• dokümantasyon
• konuşma geçmişi
• modelin akıl yürütme alanı
• ve tarayıcıdan gelen durum

Tarayıcı durumu şişerse, ilk sıkışan şey genellikle kodun kendisi olur. Agent dosyaları unutmaya, aynı şeyi tekrar okumaya ya da bağlamı özetleyip ayrıntı kaybetmeye başlar. Kompakt bir CLI akışı, o alanı asıl işe — uygulamanın koduna ve göreve — bırakır.

Ama garanti değil. Yüzlerce ekran görüntüsü alan, her adımda tam snapshot isteyen ya da devasa sayfalarda gezinen bir akış CLI ile de bağlamı doldurabilir. Kazanç, aracın kendisinden çok onu nasıl kullandığınıza bağlı.

Güvenlik ve izinler

Bir AI’ya tarayıcı erişimi vermek güçlü bir yetkidir ve dikkatle sınırlandırılmalıdır. Özellikle oturum açılmış hesaplar söz konusuysa:

• WordPress yönetim paneli
• hosting ve sunucu panelleri
• bankacılık ve ödeme sistemleri
• e-posta hesapları
• sosyal medya hesapları
• API ve bulut sağlayıcı panelleri
• müşteri bilgisi içeren sistemler
• production sunucuları

Temel ilke

AI’nın yeteneği ile AI’ya verilen izin iki ayrı şeydir.

Bir agent teknik olarak “Sil”, “Yayınla” veya “Eklentiyi Kur” butonuna tıklayabilir. Bu, tıklamasına izin verilmesi gerektiği anlamına gelmez.

Bu ayrım, AI güvenliğinin neredeyse tamamını özetliyor. Aynı konuyu gerçek bir olay üzerinden ele aldığımız AI sandbox güvenlik olayı yazımızda, bir AI agent’ın kendisine bırakılan boşlukları nasıl kullandığını ayrıntılı anlatmıştık.

Önerilen onay sistemi

Pratik yaklaşım: işlemleri ikiye ayırın.

Otomatik çalışabilir

• sayfa açmak
• frontend’i incelemek
• bağlantıları kontrol etmek
• ekran görüntüsü almak
• navigasyonu test etmek
• konsol çıktısını okumak

Onay gerektirir

• sayfa yayınlamak veya silmek
• eklenti kurmak veya kaldırmak
• kullanıcı eklemek, silmek, rol değiştirmek
• parola değiştirmek
• gerçek veri içeren form göndermek
• production ayarlarını değiştirmek
• veritabanı kaydı silmek

Ayırt edici soru basit: bu işlem geri alınabilir mi? Geri alınamıyorsa insan onayından geçmeli. Onay ekranı bir yavaşlama değil, sigortadır — ve genellikle onu ilk kez ihtiyaç duyduğunuz gün değerini fazlasıyla öder.

Staging mi, production mı?

Geliştirme sırasında AI destekli browser automation için önerilen ortam yerel (local) ya da staging.

Local / Staging
   ↓
Claude Code
   ↓
Playwright
   ↓
Test
   ↓
Geliştirici onayı
   ↓
Production

Neden? Çünkü staging’de bir şey bozulursa maliyeti zamandır; production’da bozulursa maliyeti müşteridir. Test sırasında gerçek kullanıcı verisi risk altında olmaz, tetiklenen bir form gerçek kişilere e-posta göndermez, bir ödeme akışı gerçek işlem oluşturmaz ve yoğun test trafiği paylaşımlı hosting’de komşu siteleri etkilemez.

Aynı mantığı güvenlik testi tarafında da savunuyoruz: Strix ile AI destekli pentest yazımızda da tercih edilen ortam production değil, staging kopyasıydı.

Kimler için faydalı?

• WordPress geliştiricileri — tema/eklenti değişikliklerinden sonra frontend doğrulaması.
• Frontend geliştiriciler — CSS ve yerleşim değişikliklerini tarayıcıda hızlı kontrol.
• Full-stack geliştiriciler — API değişikliğinin arayüze yansımasını uçtan uca görmek.
• QA mühendisleri — tekrarlayan regresyon kontrollerini otomatikleştirmek; ayrıca skill’ler test üretmeyi de kapsıyor.
• SaaS geliştiricileri — kayıt, giriş ve onboarding akışlarını düzenli sınamak.
• AI geliştiricileri — agent mimarilerinde bağlam bütçesini yönetmeyi öğrenmek için iyi bir örnek.
• Otomasyon geliştiricileri — tekrarlayan tarayıcı işlerini komut satırına taşımak.
• Freelancer’lar ve ajanslar — her müşteri teslimatı öncesi standart bir kontrol listesi çalıştırmak.

Playwright CLI ile ekran görüntüsü tabanlı kontrol arasındaki fark

Bazı AI tarayıcı araçları ekran görüntüsü üzerinden çalışır:

AI görseli görür
   ↓
pikselleri yorumlar
   ↓
nereye tıklayacağına karar verir (koordinat)

Playwright CLI’de ise:

AI yapılandırılmış tarayıcı durumu alır
   ↓
element ref'lerini kullanır (ör. e10)
   ↓
komutu çalıştırır

İkincisi hem daha küçük hem daha kesindir: koordinat tahmini yoktur, sayfa kayarsa yanlış yere tıklanmaz. Ama ekran görüntüleri işe yaramaz değil — görsel doğrulama için hâlâ en iyi araç. “Buton doğru yerde mi, renk kontrastı bozuk mu, mobilde taşma var mı” sorularının cevabı yapılandırılmış ağaçta değil, görüntüde. Doğru yaklaşım ikisini birlikte kullanmak: etkileşim için ref, kontrol için görüntü.

Bir uyarı daha: dokümantasyona göre ref’ler tek bir snapshot içinde geçerlidir ve sayfa değiştiğinde geçersiz olur — gezindikten sonra mutlaka yeniden snapshot alınmalıdır.

Sınırlar ve zorluklar

Playwright sihirli değil. Gerçekçi beklenti için bilinmesi gerekenler:

• Alışılmadık JavaScript davranışları — ağır animasyon, sonsuz kaydırma ve gecikmeli yüklenen içerik testleri kırılganlaştırır.
• CAPTCHA — zaten otomasyonu engellemek için vardır; aşmaya çalışmak doğru yaklaşım değildir. Test ortamında devre dışı bırakmak daha doğru bir çözümdür.
• Kimlik doğrulama — giriş akışları, 2FA ve SSO otomasyonun en zorlandığı yerdir.
• Tarayıcı uzantıları — sayfayı değiştirebilir ve testin sonucunu etkileyebilir.
• Dinamik arayüzler — Elementor düzenleyicisi gibi sürükle-bırak ağırlıklı ekranlar güvenilir otomasyon için zordur.
• Beklenmedik arayüz değişiklikleri — bir güncelleme sonrası testler sessizce kırılabilir.
• Dış servisler — ödeme sağlayıcıları, harita servisleri ve üçüncü taraf gömüler kontrolünüz dışındadır.
• İzinler ve yıkıcı işlemler — yukarıdaki onay listesi tam da bu yüzden var.
• Token kazancı değişkendir — akışa, siteye ve karşılaştırdığınız alternatife göre farklılık gösterir.

FB Software Solutions’ta nasıl bakıyoruz?

Bu tür araçları kendi geliştirme sürecimizde kullanıyoruz, ama hep aynı çerçevenin içinde: agent yalnızca izole veya staging ortamına bakar, geri alınamaz her adım insan onayından geçer, her entegrasyon yalnızca işini yapacak kadar yetki alır ve yapılan işlemler sonradan okunabilir biçimde kayıt altındadır.

Playwright CLI bu tabloda hoş bir yere oturuyor: agent’a tarayıcı verirken, ona daha az şey vererek daha çok iş yaptırmayı mümkün kılıyor. Kısıtlı bağlam, aslında disiplinli bir mimarinin doğal sonucu.

Resmî kaynaklar ve indirme bağlantıları

Playwright dokümantasyonu

Playwright’ın ana dokümantasyonu — tarayıcılar, test yazımı ve API referansı: playwright.dev/docs/intro

Coding agents rehberi

Playwright CLI’nin coding agent’lar için hazırlanmış resmî sayfası ve tam dokümantasyonu: playwright.dev/docs/getting-started-cli · playwright.dev/agent-cli

Playwright GitHub

Playwright’ın ana deposu: github.com/microsoft/playwright

Playwright CLI deposu

Playwright CLI’nin kendi deposu — README, skill dosyaları ve Apache-2.0 lisansı: github.com/microsoft/playwright-cli

Bu yazıda ayrıca şu resmî sayfalar kullanıldı: Kurulum, Hızlı başlangıç, Skills, Snapshots, Browsers ve Browser Extension.

Not: Playwright CLI hızlı gelişen bir araç. Komutlar, seçenekler ve gereksinimler zamanla değişebilir — kurulumdan önce her zaman güncel resmî dokümantasyonu kontrol edin. Bu yazıda sürüm numarası vermedik, çünkü yayın anında doğrulanabilir tek kaynak dokümantasyonun kendisi.

Playwright CLI’yi denemek ister misiniz?

Playwright’ın resmî dokümantasyonunu inceleyerek Claude Code veya başka bir coding agent ile kendi browser automation akışınızı kurabilirsiniz. Başlarken önerimiz sade: yerel ya da staging bir ortamla başlayın, geri alınamaz işlemleri onaya bağlayın ve ilk denemenizi küçük bir kontrol listesiyle yapın.