CI'da çalıştırma

Neden CI?

Uçtan uca testler yerelde ara sıra çalıştırılırsa unutulur. Her push'ta ve her pull request'te otomatik çalışan testler, bozulan akışı birleştirmeden önce yakalar. Bu derste GitHub Actions kullanıyoruz; diğer CI servislerinde adımlar aynıdır.¹

İş Akışı

npm init playwright sırasında GitHub Actions'ı seçtiyseniz dosya hazırdır. Bu rehberin projesindeki hali:¹²

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: lts/*
          cache: npm
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps chromium
      - name: Run Playwright tests
        run: npm test
      - uses: actions/upload-artifact@v5
        if: ${{ !cancelled() }}
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Adım adım:

• npm ci kilit dosyasından birebir kurulum yapar.

• npx playwright install --with-deps chromium tarayıcıyı ve Linux sistem bağımlılıklarını kurar. Yalnızca kullandığınız tarayıcıyı kurmak süreyi kısaltır.²

• npm test playwright test'i çalıştırır. webServer uygulamayı build alıp başlatır (bkz. Kurulum).

• if: ${{ !cancelled() }} testler düşse de raporun yüklenmesini sağlar. Asıl ihtiyaç duyduğunuz an testlerin düştüğü andır.¹

• timeout-minutes takılan bir işin dakikalarca çalışmasını önler.

CI İçin Yapılandırma

Oluşturulan yapılandırma process.env.CI ile CI'da farklı davranır. GitHub Actions bu değişkeni kendisi tanımlar.³

// playwright.config.ts
export default defineConfig({
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: process.env.CI ? [["github"], ["html", { open: "never" }]] : "html",
  use: {
    trace: "on-first-retry",
  },
  webServer: {
    command: "npm run build && npm run start",
    url: "http://localhost:3000",
    reuseExistingServer: !process.env.CI,
  },
});

Tek işçi yavaş gelirse güçlü bir CI makinesinde işçi sayısını artırabilir ya da testleri birden fazla makineye bölebilirsiniz.³

Raporu ve Trace'i İncelemek

Test düştüğünde Actions çalıştırmasının özet sayfasındaki Artifacts bölümünden playwright-report'u indirin, açın ve çalıştırın:¹

$ pnpm dlx playwright show-report playwright-report

retries: 2 ve trace: "on-first-retry" sayesinde düşen testin tekrar denemesinin trace'i rapordadır. Testi kendi makinenizde yeniden üretmeye çalışmadan, CI'da tam olarak ne olduğunu görürsünüz (bkz. Trace ile hata ayıklama).

Tarayıcıyı Önbelleğe Almak?

Akla gelen ilk optimizasyon tarayıcıları önbelleğe almaktır. Playwright dokümanı bunu önermez: önbelleği geri yüklemek indirmek kadar sürer ve Linux'ta sistem bağımlılıkları zaten önbelleğe alınamaz.³ actions/setup-node'un cache: npm ayarı ise npm paketlerini önbelleğe alır ve işe yarar.

Sharding: Testleri Makinelere Bölmek

Test paketi büyüyünce tek makine yetmez. --shard testleri parçalara böler; her parça ayrı bir işte çalışır:⁴

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

Her parça ayrı bir rapor üretir. Bunları tek bir HTML rapora birleştirmek için CI'da blob raporcusunu kullanın ve ayrı bir işte birleştirin:⁴

reporter: process.env.CI ? "blob" : "html",

$ pnpm dlx playwright merge-reports --reporter html ./all-blob-reports

Dokümandaki tam örnekte merge-reports işi needs: [playwright-tests] ile parçaları bekler, blob raporlarını actions/download-artifact ile tek klasöre indirir ve birleşik raporu yükler.⁴ fail-fast: false bir parça düşse de diğerlerinin bitmesini sağlar.

Birden Fazla Tarayıcı

Yerelde yalnızca Chromium, CI'da tüm tarayıcılar çalışsın istiyorsanız diğer projelere default: false verin ve CI'da hepsini seçin:⁵

- run: npx playwright install --with-deps
- run: npx playwright test --project="*"

Kırılgan Testler

Bir test bazen geçip bazen düşüyorsa kırılgandır. Google'ın test ekibi 2016'da paylaştığı verilerde test çalıştırmalarının yaklaşık yüzde 1,5'inin kırılgan sonuç verdiğini, testlerin yaklaşık yüzde 16'sında bir miktar kırılganlık olduğunu yazar. Gözlenen "geçiyordu, düştü" geçişlerinin yaklaşık yüzde 84'ü kırılgan bir testten kaynaklanır.⁶ Yani kırmızı bir CI'ın çoğu zaman gerçek bir hata olmaması, ekibin kırmızıya güvenmemeyi öğrenmesi demektir.

retries kırılganlığı gizlemez, raporlar. Bir test ilk denemede düşüp tekrar denemede geçerse rapor onu flaky olarak işaretler.⁷ Bu işareti görmezden gelmeyin:

• Trace'i açıp nedenini bulun. Çoğu zaman bir zamanlama varsayımı, paylaşılan veri ya da bir önceki testin bıraktığı durumdur (bkz. Assertion ve bekleme, Auth ve fixture).

• --repeat-each ve --shuffle ile yerelde yeniden üretin.

• Kırılganlığa hiç tahammül etmek istemiyorsanız --fail-on-flaky-tests ile flaky testleri de başarısız sayın.⁸

Martin Fowler kırılgan testleri bir karantinaya almayı önerir: ana hattan çıkarın ki sağlam testlere duyulan güven bozulmasın, ama karantinayı küçük tutun ve testleri hızla düzeltin; karantinadaki test hiçbir hatayı yakalamaz.⁹ Playwright'ta bunu bir etiket ve --grep-invert ile yapabilirsiniz:

test("ara sıra düşen test", { tag: "@quarantine" }, async ({ page }) => {
  // ...
});

$ pnpm dlx playwright test --grep-invert @quarantine

Kendin Dene

• Projenize iş akışını ekleyip bir pull request açın. Bir testi bilerek bozun ve github raporcusunun satıra yazdığı notu bulun.

• Düşen çalıştırmanın raporunu indirip trace'ini açın.

• Testleri --shard=1/2 ve --shard=2/2 ile yerelde iki parçada çalıştırın. Toplam test sayısı tutuyor mu?

• Bir testi @quarantine ile etiketleyip --grep-invert ile hariç tutun.

Detaylı Öğrenmek İçin

• Resmi doküman: Playwright, "Setting up CI"; GitHub Actions iş akışı ve raporu incelemek.¹

• Resmi doküman: Playwright, "Sharding"; parçalara bölmek ve raporları birleştirmek.⁴

• Yazı: Google Testing Blog, "Flaky Tests at Google and How We Mitigate Them"; kırılgan testlerin ölçeği ve Google'ın önlemleri.⁶

• Yazı: Martin Fowler, "Eradicating Non-Determinism in Tests"; karantina ve kırılganlığın nedenleri.⁹