Geçen hafta Maslak’taki bir ekip toplantısında yine aynı cümleyi duydum: “Testlerimiz var ama niye hâlâ prod’da sürpriz çıkıyor?” Açık konuşayım — bu sorunun cevabı çoğu zaman araçta değil, yaklaşımda gizli. Playwright tam da burada devreye giriyor; tek başına sihir yapmıyor elbette, ama doğru kurgulanırsa, yani ekip gerçekten benimsemişse ve test verisi düzgün yönetiliyorsa, yazılım kalitesini bayağı toparlıyor.
Ben Playwright’ı ilk kez 2023 sonbaharında, Kadıköy’de küçük bir SaaS ekibinin test altyapısını incelerken denemiştim. O dönemde Selenium’dan bunalmışlardı; bekleme süreleri, kırılgan locator’lar, bir de üstüne yavaş çalışan CI işleri her şeyi çorbaya çevirmişti. Playwright’a geçince ilk fark ettiğim şey hız değildi aslında. Testlerin daha az nazlandığıydı. Hani bazı araçlar vardır, sizden sürekli ekstra bakım ister; Playwright öyle değil — en azından başlangıçta (bu beni çok şaşırttı)
Bir dakika — bununla bitmedi.
Neden herkes Playwright konuşuyor?
İşin aslı şu ki Playwright’ın yükselişi biraz hak edilmiş bir yükseliş. Chromium, Firefox ve WebKit desteğini kutudan çıkar çıkmaz veriyor. Yani “ben Chrome’da çalıştım, tamam” rahatlığıyla bırakmıyor sizi; farklı motorlarda da aynı akışı görme şansı sunuyor. Bu özellikle kurumsal projelerde önemli, çünkü kullanıcı kitlesi tek tarayıcıya sıkışmıyor.
Bir de API tarafı var. Birçok ekip UI — itiraz edebilirsiniz tabi — testi ayrı, API testi ayrı diye iki farklı dünya kuruyor — ve o iki dünya birbirine selam bile vermiyor. Playwright bu ayrımı bayağı yumuşatıyor. Aynı test çatısı içinde hem arayüzü hem servisi kontrol edebiliyorsunuz. Küçük startup için avantaj açık: daha az araç, daha az bakım yükü. Enterprise tarafta ise mesele farklı; orada standardizasyon ve izlenebilirlik kazanıyorsunuz. İkisi de değerli, ama farklı nedenlerle.
Kısa karşılaştırma masaya gelsin
| Özellik | Playwright | Selenium | Cypress |
|---|---|---|---|
| Tarayıcı desteği | Chromium / Firefox / WebKit | Geniş ama ek kurulum ister | Daha sınırlı |
| API testi | Evet | Ayrı araç gerekir | Sınırlı kalır |
| Otomatik bekleme | Baya iyi | Manuel yönetim gerekebilir | Var ama kullanım alanı daralabiliyor |
| Kod yapısı | TypeScript ile çok temiz gidiyor | Daha eski alışkanlıklar baskın olabilir | Tatlı ama bazen kapalı kutu gibi hissedilir |
Bakın, Açıkçası ben bu tabloyu her projede birebir uygulamam; çünkü her takımın olgunluğu farklı. Ama genel resimde Playwright’ın modern bir omurga sunduğunu söylemek zor değil.
Kurulum kısmı neden sandığınız kadar sıkıcı değil?
Bundan iki ay önce Beşiktaş’ta bir fintech ekibiyle otururken yeni test projesini ayağa kaldırdık. Eski düzenlerinde dizin yapısı o kadar karışıktı ki kimse hangi testin neyi kırdığını bulamıyordu. Yeni başlangıçta yaptığımız ilk şey klasörleri net ayırmak oldu: unit, integration, api ve e2e. Basit gibi duruyor — ama düzen dediğin şey zaten küçük kararların toplamıdır.
npm init playwright@latest
Güzel taraf şu: sizi çok fazla el işiyle boğmuyor. TypeScript seçiyorsunuz, test klasörünü belirliyorsunuz, isterseniz GitHub Actions akışını da ekliyorsunuz — hepsi yerine oturuyor. Ama küçük bir uyarı bırakayım: proje büyüdükçe varsayılan yapı yetmemeye başlıyor. Peki bunu neden söylüyorum? Orada kendi fixture katmanınızı ve yardımcı fonksiyonlarınızı erkenden koymazsanız, ileride ufak karmaşa büyüyüp sizi bunaltabiliyor.
Klasör yapısını sade tutmak iş görüyor mu?
Evet. Bayağı görüyor. Mesela de yeni gelen geliştiriciler için “test nerede?” sorusunu neredeyse sıfıra indiriyor.
playwright-fullstack-tests/
├── tests/
│ ├── unit/
│ ├── integration/
│ ├── api/
│ └── e2e/
├── pages/
├── fixtures/
├── test-data/
├── utils/
└── playwright.config.ts
Ne yalan söyleyeyim, Neyse uzatmayayım: yapı ne kadar temizse CI’da debug etme süresi o kadar düşüyor (ben de ilk duyduğumda şaşırmıştım) Python CLI Dağınıklığına Son: Klix Neyi Farklı Yapıyor? yazımızda bu konuya da değinmiştik.
POM meselesi: Faydalı mı yoksa fazladan katman mı?
Bazıları Page Object Model’i duyunca göz deviriyor. Haksız sayılmazlar aslında, çünkü kötü uygulanmış POM gerçekten hantallaştırabiliyor kodu. Benim görüşüm net: küçük projede aşırı soyutlama yapmak gereksizdir. Ama ekran sayısı arttıkça POM hayat kurtarıyor — bunu gördüm, yaşadım.
Ankara’da çalışan bir arkadaşım geçen yıl bana şöyle demişti: “Login ekranındaki tek değişiklik yüzünden altı test patladı.” İşte POM’un olayı tam burada belli oluyor. Locator’ları tek yerde toplarsanız bakım yükü ciddi düşüyor.
Peki her şeyi sınıf yapmalı mısınız?
Hayır. Bakın şimdi — bazı ekipler bunu yanlış anlıyor. Her butonu ayrı method’a çeviriyor; sonunda okunması zor, içinden çıkılmaz minik romanlar ortaya çıkıyor. E peki, sonuç ne oldu? Bence login gibi tekrar eden akışlarda mantıklı kullanın, geri kalanında sade kalın.
- Küçük startup: Az sayıda page object yeterli olur. — ciddi fark yaratıyor
- Büyüyen ürün ekipleri: Ortak bileşenler için page object mantıklı hale gelir. (bence en önemlisi)
- Kurum içi platformlar: Standartlaştırılmış POM uzun vadede rahatlatır.
“POM’u fazla şişirirseniz testleriniz anlaşılır olmaktan çıkar; az kullanırsanız bakım kabusu başlar.” Benim pratikte gördüğüm denge tam olarak bu aralıkta duruyor.
API + UI + entegrasyon birlikte nasıl yürür?
İşte burası bana göre Playwright’ın asıl numarasını yaptığı yer. Sadece tıklama yapan bir otomasyon aracı olmaktan çıkıp sistem davranışını bütünüyle görmenizi sağlıyor. Daha fazla bilgi için CSS3 ile Düğme Tasarımını İyi Yapmanın İncelikleri yazımıza bakabilirsiniz.
Açık konuşayım, Bir örnek vereyim: ürün detay sayfasını UI’dan açmadan önce API ile ürünü hazırladığınızda testiniz hem hızlanıyor hem de daha güvenilir oluyor — tabii servis katmanı sağlamsa. Geçen mart ayında İzmir’de yaptığım bir demo sırasında bunu gösterince ekipten biri “Yani önce veriyi oluşturup sonra arayüzü mü kontrol ediyoruz?” diye sordu. Aynen öyle!
Bu yöntem özellikle regresyon setlerinde işe yarıyor çünkü tüm hazırlığı tarayıcı üzerinden yapmak yerine doğrudan servis çağrılarıyla hallediyorsunuz. Dur bir saniye — burada hayati nokta hız değil sadece; deterministik sonuç almak asıl kazanç. Aynı senaryoda UI yalnızca doğrulama katmanı oluyor.
Basit bir örnek akış nasıl görünür?
import { test, expect } from '@playwright/test';
test('kullanıcı oluşturma ve arayüzde doğrulama', async ({ request, page }) => {
const response = await request.post('/api/users', {
data: { name: 'Deniz', role: 'editor' }
});
expect(response.ok()).toBeTruthy();
await page.goto('/users');
await expect(page.getByText('Deniz')).toBeVisible();
});Vallahi, Bunu ilk kez gerçek projede kullandığımda fark ettim ki en büyük kazanç “beklemek” kısmının azalmasıydı. Mesela gece koşan CI işlerinde beş dakikalık fark bazen hiçbir şey gibi görünmez… ta ki on ayrı pipeline olduğunda süre uçup gidene kadar.
CI/CD’ye bağlayınca işler neden değişiyor?
E tabi, yerelde çalışan test başka şeydir — CI içinde yaşayan test bambaşka şeydir. Bursa’daki orta ölçekli bir ürün takımında gördüğüm en klasik hata şuydu: yerelde yeşil olan suite CI’da kırmızıya dönüyordu. Sebep? Paralel çalışma ayarı yoktu ve ortam verisi rastgele yönetiliyordu. Yani sorun koddan çok çalışma biçimindeydi. Common Lisp ile MCP Sunucusu Kurmak: Günler Değil Dakikalar yazımızda bu konuya da değinmiştik.
Playwright burada fena değil, hatta bayağı iyi, çünkü paralel koşuyu doğal destekliyor (bizzat test ettim). Ama şunu net söyleyeyim: CI entegrasyonu güzel bir özellik, (yanlış duymadınız). Flaky test temizliği yapılmazsa sonuçlar kafa karıştırmaya devam ediyor.
Dikkat edilmesi gerekenler neler?
- Aynı veriyi paylaşmayın: Paralel koşuda çakışma çıkarabilir.
- Retries’ları abartmayın: Hata saklamak yerine kök sebebi bulun.
- Raporlamayı görünür tutun: Sadece kırmızı/yeşil yetmez.
- Headless modunu üretime yakın kullanın: Yoksa sürpriz yaşarsınız.
Kendi deneyimimde en faydalı adım log seviyesini artırmak oldu. Mesela de son iki yılda debug ekran görüntüsü ve trace kombinasyonu beni birkaç kez kurtardı. Hatta Nisan ayının başında İstanbul Kartal’daki ofiste buna güvenerek yarım günlük hatayı on dakikada bulduk. Kötü haber şu: iyi raporlamanız yoksa otomasyonun kendisi size yük olur.
Ne zaman Playwright yetmez?
Burasını özellikle dürüstçe yazmak istiyorum. Her parlak aracın sınırı var. Playwright hızlıdır ama kötü mimariyi düzeltemez. Test veriniz dağınıksa, locator’larınız stabil değilse ve ekipte ortak disiplin yoksa (en azından benim deneyimim böyle). araç sadece semptomu örter. Hepsi bu.
Benim gördüğüm hayal kırıklığı genelde burada yaşanıyor: takımlar araca fazla anlam yüklüyor. “Playwright aldık mı sorun çözülür” düşüncesi maalesef yanlış. Araç tamam, ama süreç de tamam olmalı.
Şimdi gelelim pratik önerilere. Eğer küçük bir startup iseniz, — itiraz edebilirsiniz tabi — önce kritik müşteri yolculuklarını kapsayın: giriş, satın alma, ödeme sonrası doğrulama gibi akışlar yeterli. Enterprise seviyede ise risk bazlı genişletme yapmanız gerekir; her ekranı değil, iş açısından önemli yolları hedefleyin.
Kendi blog masamda not aldığım küçük kural şu: bir özelliği üç kez elle doğruluyorsanız onu otomasyona aday kabul edin. Bu kural mucize yaratmaz ama filtre görevi görüyor.
TypeScript’i Öğrenmek İçin Sıfırdan Form Doğrulama Yazmak yazısındaki yaklaşımı hatırlıyorum; orada da konu sadece kod yazmak değildi, düşünce biçimini değiştirmekti. Test otomasyonunda da hikâye biraz böyle.
Kod Kapsama Araçları: 2026’da En İyiler ve Gerçekler
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
