Playwright 1.65 Yenilikleri: Bun Desteği, Yalnızca Hata Raporları ve Yükseltme Rehberi

Playwright 1.65, 5 Kasım 2026'da yayımlandı: test koşucusu artık Bun altında da çalışabiliyor, ama aynı sürüm yeşil koşan testleri kırmızıya çevirebilecek değişiklikler de içeren on maddelik bir "dikkat" listesi getiriyor.¹ Bu yazıda Playwright 1.65'in yeni özelliklerini (Bun desteği, yalnızca hataları gösteren raporlar, -exclusive- kilidi) kısa örneklerle ele alıyor, ardından yükseltmeden önce kontrol etmeniz gereken değişiklikleri tek tek açıklıyoruz. Son bölümde yükseltmenin kendisini nasıl test edeceğinizi; karışık sıralı koşu, küçük "kanarya" testleri ve shard'lı bir CI iş akışıyla adım adım gösteriyoruz. Playwright'ın genel yapısına yabancıysanız önce Playwright mimarisini anlatan yazıya göz atabilirsiniz.

Playwright 1.65'te neler var? Kısa özet

GitHub'daki v1.65.0 sürümü 5 Kasım 2026 tarihli; npm'de hem @playwright/test hem de playwright paketlerinin güncel sürümü 1.65.0.² Aynı notlar playwright.dev'deki sürüm notları sayfasında da yer alıyor.³ Sürümle birlikte gelen tarayıcılar Chromium 158.0.8127.18, Firefox 159.0 ve WebKit 27.2; sürüm ayrıca kararlı kanaldaki Google Chrome 157 ve Microsoft Edge 156 ile de test edilmiş.¹

Değişiklikleri kimi ilgilendirdiğine göre gruplarsak tablo şöyle:

Playwright testlerini Bun ile çalıştırmak

Bun, Node.js'e alternatif bir JavaScript çalışma zamanıdır (runtime). Playwright 1.65 ile test koşucusu Bun altında da çalışabiliyor. Bu modda TypeScript test dosyalarını Bun kendisi dönüştürüyor (transpile ediyor); Playwright bu durumda Babel'i ve kendi derleme önbelleğini kullanmıyor.¹

bunx --bun playwright test

En kolay gözden kaçacak ayrıntı --bun bayrağı. Sürüm notlarına göre bu bayrak olmadan bunx playwright test komutu testleri yine Node.js üzerinde çalıştırıyor.¹³ Yani paket yöneticisini Bun'a çevirip "artık Bun'da koşuyoruz" sanarken aslında Node.js'te koşmaya devam etmek mümkün. CI betiklerinizde bayrağın gerçekten yer aldığını kontrol edin.

Bun altında farklı çalışan özellikler

Playwright ekibi, test koşucusunun kendi testlerini Linux üzerinde Bun 1.4.3 ile çalıştırıyor.¹ Sürüm notları bazı özelliklerin Bun altında farklı davrandığını açıkça listeliyor:

• İzleme (watch) modu yok. UI modu dosyalar değişince testleri yeniden çalıştırmıyor; --only-changed bayrağı import zincirini takip etmiyor.
• Modülleri Bun yüklüyor. Bu yüzden --tsconfig bayrağı ve tsconfig.json'daki JSX seçenekleri etkisiz kalıyor; özel ESM yükleyicileri (loader) desteklenmiyor.
• Hata yığınları daha yoksul. Stack trace'lerde async çerçeveler yok ve API adlarında sınıf adı yer almıyor: locator.click yerine yalnızca click görünüyor. Bu da bazı adım konumlarını, adım başlıklarını ve hata mesajlarını değiştiriyor.
• Konsol çıktısı kayboluyor. Testin konsol çıktısı trace dosyasına ve UI moduna aktarılmıyor.

Son iki madde hata ayıklamayı doğrudan etkiliyor: adım başlıkları ve trace'teki konsol çıktısı Bun altında daha az bilgi veriyor. Bunları ayrıştıran (parse eden) özel bir raporlayıcınız varsa farklı metinler görecek.

Önerimiz şu: Bun'u ana test koşunuzun yerine hemen koymayın; CI'da başarısız olması birleştirmeyi engellemeyen ayrı bir iş (job) olarak deneyin ve iki koşunun süresini ve sonuçlarını kendi projenizde karşılaştırın. Sürüm notları Bun ile ilgili herhangi bir performans karşılaştırması içermiyor; "daha hızlı olur" varsayımını kendi ölçümünüzle doğrulayın.

Yalnızca hataları gösteren raporlar: failures ve onlyFailures

Büyük test takımlarında CI çıktısının çoğu geçen testlerden oluşur; gerçekten bakılması gereken birkaç hata bu kalabalıkta kaybolur. Playwright 1.65 bu soruna iki yeni araçla yaklaşıyor.¹

failures raporlayıcısı

Yeni failures raporlayıcısı, hataları ve yeniden denemede (retry) geçen testleri oluştukları anda yazdırıyor, en sonda da bir özet veriyor; ilerleme çıktısı üretmiyor.⁴ Yapılandırmaya dokunmadan denemek için komut satırı yeterli:

npx playwright test --reporter=failures

onlyFailures seçeneği

onlyFailures ise ayrı bir raporlayıcı değil, HTML, JSON ve JUnit raporlayıcılarına eklenen bir seçenek. Açıldığında rapora yalnızca beklenmeyen sonuç veren testler (beklenmedik şekilde geçenler dahil), kararsız (flaky) testler ve yarıda kesilen testler giriyor. Dokümantasyona göre kararsız testler yeniden denemede geçse bile rapora dahil ediliyor ve dahil edilen bir testin, başarılı yeniden denemeleri de dahil olmak üzere tüm denemeleri saklanıyor.⁴

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['failures'],
    ['html', { onlyFailures: true }],
  ],
});

Bu ikili özellikle CI için anlamlı: konsolda failures kısa ve okunur bir çıktı verirken, HTML raporu yalnızca incelenmesi gereken testleri içerdiği için CI'ın sakladığı rapor dosyaları (artefakt) da sadeleşir.

Test koşucusundaki diğer yenilikler

-exclusive- kilidi ile tek başına koşan testler

Test kilitleri (test locks) 1.63 ile geldi: aynı kilit adını taşıyan testler dosyalar, worker'lar ve projeler arasında hiçbir zaman eş zamanlı çalışmıyor, geri kalan testler ise paralel koşmaya devam ediyor.⁵ 1.64, test.describe.configure() için lock seçeneğini ekledi.⁶ Playwright 1.65 ise yerleşik -exclusive- kilidini getiriyor: bu kilidi taşıyan test, başka hiçbir test çalışmıyorken başlıyor ve o bitene kadar başka test başlamıyor.⁷

import { test } from '@playwright/test';

test('test sunucusunu yeniden başlat', { lock: '-exclusive-' }, async () => {
  // Bu test çalışırken başka hiçbir test çalışmaz.
});

test('profil ayarlarını güncelle', { lock: ['veritabani', 'dis-api'] }, async ({ page }) => {
  // Yalnızca iki kilit de boştayken çalışır.
});

Örnekteki ikinci test, dokümantasyonda anlatılan çoklu kilit kullanımını gösteriyor: bir test birden fazla kilit tanımlayabiliyor ve ancak hepsi boşta olduğunda çalışıyor.⁷ -exclusive- için tipik adaylar; test ortamındaki bir servisi yeniden başlatan, global bir ayarı değiştiren ya da paylaşılan önbelleği temizleyen testler.

Bir uyarı: dokümantasyon kilitlerin "dosyalar, worker süreçleri ve projeler arasında" çalıştığını söylüyor, farklı makinelerde koşan shard'lardan ise söz etmiyor.⁷ Shard'lar ayrı makinelerde çalıştığı için -exclusive- kilidinin başka bir shard'daki testleri durduracağını varsaymayın. Böyle bir test gerçekten tüm ortamı etkiliyorsa, onu ayrı bir CI adımına almak daha güvenli bir öneri.

test.skip('açıklama') ile gerekçeli atlama

test.skip(), test.fixme(), test.fail() ve test.slow() artık yalnızca bir açıklama metniyle de çağrılabiliyor; açıklama testin ek bilgisine (annotation) kaydediliyor.¹ Koşullu imzalar dokümantasyonda yerini koruyor; yeni olan, koşul vermeden doğrudan gerekçe yazabilmek.⁸

test('fatura PDF indirme', async ({ page }) => {
  test.skip('PDF servisi test ortamında henüz yok');
  // ...
});

Raporda "neden atlandı?" sorusunun cevabı görüneceği için bu kısayol, sprint sonunda atlanan testleri gözden geçiren QA ekiplerinin işini kolaylaştırır.

Küçük ama kullanışlı eklemeler

• PLAYWRIGHT_TRANSFORM_CACHE_DIR ortam değişkeni, dönüştürülmüş test dosyalarının konacağı klasörü belirliyor; örneğin başka kullanıcılarla paylaşılan bir Linux makinesinde işe yarıyor.¹
• cdpSession.send() artık timeout ve signal seçeneklerini alıyor. Böylece Chrome DevTools Protocol (CDP) çağrıları zaman aşımıyla ya da bir AbortSignal ile iptal edilebiliyor.¹
• testRun.mode(), özel raporlayıcıların reporter.preprocess() aşamasında bir test takımının (suite) çalışma modunu öğrenmesini sağlıyor.¹

Playwright 1.65'te dikkat gerektiren değişiklikler

Sürüm notlarının "Notable Changes" bölümünde on madde var. Bir kısmı hata düzeltmesi gibi görünse de mevcut testlerin sonucunu, raporların içeriğini ya da CI davranışını değiştirebilir. Aşağıda test kodunu en doğrudan etkileyenleri örnekleriyle anlatıyor, kalanları bir tabloda topluyoruz.¹

Page Object sınıflarında alan başlatıcıları

Playwright artık TypeScript sınıf alanlarında tsconfig.json'daki useDefineForClassFields ayarına uyuyor; yani tsc ile aynı davranıyor. Sürüm notlarına göre bu ayar ES2022 ve sonrası hedeflerde (target) ve target hiç belirtilmediğinde açık.¹ Ayar açıkken sınıf alanı başlatıcıları (field initializer) constructor gövdesinden önce çalışır ve constructor'ın parametre özelliklerine (parameter property) erişemez.⁹ Page Object kalıbında çok yaygın olan şu kullanım bu yüzden 1.65'te hata veriyor:

import type { Page } from '@playwright/test';

export class GirisSayfasi {
  // 1.65: TypeError: Cannot read properties of undefined (reading 'getByRole')
  readonly gonder = this.page.getByRole('button', { name: 'Giriş yap' });

  constructor(private readonly page: Page) {}
}

İki çözüm var. Sürüm notlarının önerdiği ilk yol, atamayı constructor'a taşımak:

import type { Locator, Page } from '@playwright/test';

export class GirisSayfasi {
  readonly gonder: Locator;

  constructor(private readonly page: Page) {
    this.gonder = page.getByRole('button', { name: 'Giriş yap' });
  }

  async ac() {
    await this.page.goto('/giris');
  }
}

İkinci yol tsconfig.json'da "useDefineForClassFields": false ayarlamak; Playwright'ın TypeScript dokümantasyonu bunu eski TypeScript davranışını korumanın yolu olarak gösteriyor.⁹ Kalıcı çözüm olarak birinci yolu öneriyoruz: ayarı kapatmak projenin geri kalanında da sınıf alanlarının anlamını değiştirir ve sorunu yalnızca erteler. Etkilenebilecek dosyaları kabaca bulmak için şu arama işe yarar:

grep -rnE "^\s*(readonly\s+)?\w+\s*=\s*this\.page\." tests/ pages/

inert öğelerde eylemler artık bekliyor

HTML'deki inert özniteliği, bir öğeyi ve tüm alt öğelerini kullanıcı etkileşimine kapatır; modal açıkken arka planı kilitlemek için sık kullanılır. Playwright 1.65'ten itibaren click(), check(), tap(), fill(), clear() ve selectOption() gibi eylemler öğenin inert olmamasını bekliyor; öğe inert kalırsa eylem zaman aşımına uğruyor.¹ Actionability dokümantasyonundaki tabloya göre bu kontrol dblclick(), setChecked() ve uncheck() için de yapılıyor; hover(), press(), focus() ve setInputFiles() gibi eylemlerde ise yapılmıyor.¹⁰

Pratikte bu, gerçek bir kullanıcının da etkileşime giremeyeceği öğeleri hedefleyen testlerin artık açıkça zaman aşımına uğraması demek. Böyle bir hatayı gördüğünüzde ilk bakılacak yer, testin modalı ya da çekmeceyi kapatmadan arka plandaki bir öğeye dokunmaya çalışıp çalışmadığı. Kapanışı açıkça doğrulayan bir adım hem testi düzeltir hem de niyeti belgeler (temsili örnek):

test('modal kapandıktan sonra profil sayfasına geçilir', async ({ page }) => {
  await page.goto('/ayarlar');
  await page.getByRole('button', { name: 'Hesabı sil' }).click();

  const dialog = page.getByRole('dialog');
  await expect(dialog).toBeVisible();
  await dialog.getByRole('button', { name: 'Vazgeç' }).click();
  await expect(dialog).toBeHidden();

  // Arka plan hâlâ inert ise 1.65'te bu tıklama zaman aşımına uğrar.
  await page.getByRole('link', { name: 'Profil' }).click();
});

Boş shard koşuları ve --pass-with-no-tests

--shard bayrağı test takımını birden fazla makineye bölmenizi sağlıyor (örneğin --shard=2/4).¹¹ Playwright 1.65'te bölünmüş bir koşuda tüm shard'lar genelinde hiçbir test eşleşmezse koşu "No tests found" hatasıyla başarısız oluyor. Tek bir shard'ın boş kalması ise, diğer shard'larda test olduğu sürece sorun değil.¹

Bu değişikliğin yakaladığı asıl hata, yanlış yazılmış bir --grep ya da dosya filtresi yüzünden aslında hiçbir şey koşmayan ama yeşil görünen CI işleri. Boş koşu bilinçliyse --pass-with-no-tests bayrağı koşuyu başarılı sayıyor.¹¹ Önerimiz, bu bayrağı her işe varsayılan olarak eklememek; yalnızca filtrenin gerçekten boş dönebileceği işlerde kullanmak.

Çerezler, proxy kimlik bilgileri ve params

API testi yazan ekipleri en çok şu üç değişiklik ilgilendiriyor:¹

• Çerez eşleşmesi RFC 6265'e uyuyor. RFC 6265, HTTP çerezlerinin nasıl eşleşeceğini tanımlayan standarttır. URL verildiğinde browserContext.cookies() ve apiRequestContext.cookies() artık alt alan adları için host-only çerezleri ya da /apiv2 için Path=/api çerezlerini döndürmüyor; Path=/foo/ çerezi de /foo ile eşleşmiyor. Ayrıca APIRequestContext, adı olmayan bir çerezi Cookie: =x yerine Cookie: x olarak gönderiyor.
• Proxy kimlik bilgileri sitelere gitmiyor. proxy seçeneğindeki kimlik bilgileri artık yalnızca proxy'nin kimlik doğrulama isteklerine (challenge) yanıt veriyor. Siteye kimlik doğrulaması gerekiyorsa httpCredentials kullanılmalı.
• params mevcut sorguya ekleniyor. APIRequestContext isteklerinde params seçeneğine verilen string ve URLSearchParams değerleri, URL'deki mevcut sorgu dizesinin yerine geçmek yerine artık ona ekleniyor.

params değişikliği özellikle sinsi olabilir: URL'de zaten ?sayfa=1 bulunan bir istekte params ile sayfa=2 gönderen eski bir test, artık iki parametreyi birden taşıyan bir istek üretebilir. Bu davranışı test bölümünde küçük bir kanarya testiyle sabitleyeceğiz.

Diğer değişiklikler bir bakışta

Node.js 20 desteği ve Docker imajları

Playwright 1.65 artık Node.js 20 üzerinde test edilmiyor; ekip Node.js 22, 24 veya 26 kullanılmasını öneriyor.¹ Kurulum dokümantasyonundaki sistem gereksinimleri de 22.x, 24.x ya da 26.x serisinin son sürümünü istiyor.¹² Dikkat çekici bir ayrıntı: npm paketindeki engines alanı hâlâ node >=20 gösteriyor.² Yani Node.js 20'de kurulum engellenmiyor, ama bu ortam artık resmi olarak test edilen bir ortam değil. CI'ınız Node.js 20'de kaldıysa, Playwright'tan önce Node.js'i güncellemek en güvenli sıra.

Resmi Docker imajları da Node.js 24 yerine Node.js 26 içeriyor.¹ Bu geçişin bir yan etkisi GitHub'da kayda geçti: 12 Kasım 2026'da açılan bir kayıt, daha önce yayımlanmış v1.64.1 imajlarının sonradan Node.js 26 ile yeniden yayımlandığını ve sürümü sabitlemiş ekiplerin CI'ının kırıldığını bildirdi. Playwright ekibi bunun bir hata olduğunu kabul etti ve politikasını güncelledi: bundan sonra bir Playwright minor sürümündeki tüm imajlarda Node.js major sürümü aynı kalacak; yeni bir Node.js major sürümü yalnızca yeni bir Playwright minor sürümüyle gelecek. Ekip, 1.64 imajlarını yeniden yayımlamayı planlamadığını da belirtti.¹³

Docker dokümantasyonu imajı belirli bir sürüme sabitlemenizi öneriyor ve imajdaki Playwright sürümü projedekiyle eşleşmezse Playwright'ın tarayıcı dosyalarını bulamayacağını belirtiyor.¹⁴ Bu yazı hazırlanırken dokümantasyondaki örnek etiket hâlâ v1.64.1-noble idi; 1.65 etiketine geçmeden önce kullanacağınız etiketin kayıt defterinde (registry) bulunduğunu kontrol edin. Node.js major sürümünün hiç değişmemesi sizin için kritikse, etiket yerine imaj özetiyle (digest, @sha256:…) sabitlemek ek bir güvence sağlar.

Playwright 1.65 yükseltmesi nasıl test edilir?

Bir test aracını yükseltmek, test altyapınızda yapılan bir değişikliktir ve kendisi de test edilmelidir. Aşağıdaki dört adım yükseltmeyi küçük ve geri alınabilir parçalara bölüyor. Hangi testlerin önce koşacağına karar verirken regresyon testi kapsamı belirleme yazısındaki yaklaşım da işinize yarar.

1. Sürümü ayrı bir dalda sabitleyin

node -v
git switch -c chore/playwright-1-65
npm install -D --save-exact @playwright/test@1.65.0
npx playwright install --with-deps
npx playwright --version

--save-exact, package.json'a ^1.65.0 yerine tam sürümü yazar. Bu, paketi, tarayıcıları ve Docker imaj etiketini aynı sürümde tutmayı kolaylaştırır; ana dal ise yükseltme bitene kadar eski sürümle çalışmaya devam eder.

2. Testleri karışık sırayla ve yalnızca hata çıktısıyla koşun

1.64'te gelen --shuffle bayrağı testleri rastgele sırayla planlıyor ve çıktıya bir tohum (seed) değeri yazıyor; aynı tohumu vererek aynı sırayı yeniden üretebiliyorsunuz.⁶ Yükseltme koşusunda bunu failures raporlayıcısıyla birleştirmek, hem birbirine gizlice bağımlı testleri hem de 1.65'in davranış değişikliklerini tek seferde görünür kılar:

npx playwright test --shuffle --reporter=failures

# Çıktıdaki tohumu not edin; aynı sırayı tekrar üretmek için:
npx playwright test --shuffle 271828182 --reporter=failures

Kırmızıya dönen her testi yukarıdaki değişiklik listesiyle eşleştirin. Önerdiğimiz ilk bakış sırası şöyle: TypeError ile düşen kurulum kodu için sınıf alanları; eylem zaman aşımları için inert kontrolü; getByRole() uyuşmazlıkları için erişilebilir ad değişikliği; API testlerindeki beklenmedik çerez ya da sorgu farkları için RFC 6265 ve params. Listede karşılığı olmayan bir hata, gerçek bir regresyon ya da önceden var olan bir sıra bağımlılığı olabilir.

3. Değişen davranışları kanarya testleriyle sabitleyin

Kanarya testi, bir bağımlılığın davranışını doğrudan doğrulayan küçük bir testtir: bir sonraki yükseltmede davranış yine değişirse ilk o kırılır ve sorunun kaynağını hemen gösterir. Aşağıdaki temsili örnek, params ve çerez değişikliklerini yerel bir HTTP sunucusuna karşı doğruluyor; dış ağa bağımlı değil:

// tests/kanarya/playwright-1-65.spec.ts — temsili örnek
import { test, expect } from '@playwright/test';
import http from 'node:http';
import type { AddressInfo } from 'node:net';

let server: http.Server;
let baseURL: string;

test.beforeAll(async () => {
  server = http.createServer((req, res) => {
    res.setHeader('content-type', 'application/json');
    res.end(JSON.stringify({ url: req.url }));
  });
  await new Promise<void>((resolve) => server.listen(0, '127.0.0.1', resolve));
  baseURL = `http://127.0.0.1:${(server.address() as AddressInfo).port}`;
});

test.afterAll(async () => {
  await new Promise((resolve) => server.close(resolve));
});

test('params mevcut sorgu dizesine eklenir', async ({ request }) => {
  const res = await request.get(`${baseURL}/ara?dil=tr`, { params: 'q=playwright' });
  const { url } = await res.json();
  expect(url).toContain('dil=tr');
  expect(url).toContain('q=playwright');
});

test('Path=/api çerezi /apiv2 adresiyle eşleşmez', async ({ request }) => {
  await request.addCookies([{ name: 'oturum', value: '42', domain: '127.0.0.1', path: '/api' }]);
  expect(await request.cookies(`${baseURL}/api/profil`)).toHaveLength(1);
  expect(await request.cookies(`${baseURL}/apiv2/profil`)).toHaveLength(0);
});

apiRequestContext.addCookies() ve cookies() yöntemleri 1.64'te eklendi; bu dosya 1.64'te kırmızı, 1.65'te yeşil olmalı ve tam da bu yüzden bir kanarya işlevi görüyor.⁶ Page Object'ler için de her sınıfı bir kez oluşturan küçük bir test eklemek, alan başlatıcısı sorunlarını uzun senaryolara girmeden yakalar.

4. CI'da shard'lı koşu ve yalnızca hata raporu

Yerelde yeşile döndükten sonra yükseltmeyi CI'a alın. Aşağıdaki temsili yapılandırma, CI'da konsola failures çıktısı veriyor ve yalnızca sorunlu testleri içeren bir HTML raporu üretiyor (open: 'never', raporun tarayıcıda otomatik açılmasını engelliyor):⁴

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: process.env.CI
    ? [['failures'], ['html', { onlyFailures: true, open: 'never' }]]
    : 'list',
});

GitHub Actions tarafında testleri dört shard'a bölen temsili bir iş akışı:

# .github/workflows/e2e.yml
name: e2e
on: [pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4
      - uses: actions/upload-artifact@v7
        if: ${{ !cancelled() }}
        with:
          name: playwright-report-${{ matrix.shard }}
          path: playwright-report/
          retention-days: 7

Birkaç not: Node.js sürümünü 22, 24 veya 26'dan biri olarak açıkça yazın; Playwright'ın sharding dokümantasyonundaki örnek lts/* kullanıyor.¹⁵ Shard raporlarını tek bir HTML raporunda birleştirmek isterseniz, shard'larda blob raporlayıcısını kullanıp ardından npx playwright merge-reports çalıştırın. Dokümantasyona göre onlyFailures'ın birleştirilmiş rapora uygulanması için yapılandırma dosyasını --config ile vermeniz gerekiyor.⁴¹⁵ Son olarak bu iş akışına bilerek --pass-with-no-tests eklemedik: filtre yanlışlıkla boş dönerse işin kırmızı olması tam da istenen davranış.