Porównanie Cypress i Playwright dla projektu w Next.js

Pytanie brzmi: który z nich lepiej pasuje do projektu opartego na Next.js?

Cypress vs Playwright w Next.js — szybkie porównanie

Cypress i Playwright — krótka historia narzędzi E2E

Cypress pojawił się w 2017 roku i bardzo szybko stał się standardem w świecie frontendowym, a jego największą zaletą było rewolucyjne podejście do debugowania testów – time travel, automatyczne snapshoty i interaktywny runner.

Playwright to nieco świeższy projekt z 2020 roku, stworzony przez Microsoft, a konkretnie przez byłych twórców Puppeteera. Od początku swojego istnienia stawiał na wieloprzeglądarkowe wsparcie i szybkość działania.

Doświadczenie deweloperskie w Cypress i Playwright

Cypress DX — interaktywny runner i debugowanie

Cypress słynie z fenomenalnego DX, ponieważ interaktywny Test Runner pozwala obserwować testy w czasie rzeczywistym, klikać w poszczególne kroki i widzieć stan DOM w danym momencie. To wygodne i jednocześnie bardzo ułatwia "wejście" do testowania dla nowych, uczących się użytkowników.

// cypress/e2e/homepage.cy.ts
describe('Homepage', () => {
  it('should display hero section', () => {
    cy.visit('/')
    cy.get("[data-testid='hero-title']").should('be.visible')
    cy.get("[data-testid='cta-button']").click()
    cy.url().should('include', '/signup')
  })
})

Składnia oparta na chainingu jest prosta i intuicyjna, choć wymaga zrozumienia asynchronicznej natury komend Cypress – nie są to zwykłe Promise'y.

Playwright DX — trace viewer i testy cross-browser

Playwright oferuje natywne wsparcie dla async/await, co jest bardziej naturalne dla deweloperów znających JavaScript/TypeScript.

// tests/homepage.spec.ts
import { test, expect } from '@playwright/test'
 
test('should display hero section', async ({ page }) => {
  await page.goto('/')
  await expect(page.getByTestId('hero-title')).toBeVisible()
  await page.getByTestId('cta-button').click()
  await expect(page).toHaveURL(/signup/)
})

Warto też dodać, że Playwright ma wbudowany codegen – narzędzie nagrywające interakcje w przeglądarce i generujące gotowy kod testów.

Szybkość testów E2E w Cypress i Playwright

Nie da się uczciwie wskazać szybszego runnera bez uruchomienia obu narzędzi na tej samej aplikacji, infrastrukturze i zestawie scenariuszy. Można natomiast porównać ich model wykonania:

• Playwright Test domyślnie wykonuje pliki testowe równolegle w osobnych workerach. Testy wewnątrz jednego pliku pozostają sekwencyjne, chyba że włączysz fullyParallel lub tryb parallel,
• Cypress wykonuje specy sekwencyjnie w pojedynczym procesie. Możesz rozdzielić pliki między joby samodzielnie albo użyć Cypress Cloud do dynamicznego balansowania,
• Playwright udostępnia izolowane BrowserContext, dzięki czemu worker może wydajnie uruchamiać kolejne testy bez współdzielenia cookies i storage,
• oba narzędzia ponoszą koszt uruchomienia przeglądarek, aplikacji Next.js, przygotowania danych oraz zapisu wideo, screenshotów i trace'ów.

W praktyce różnice w CI najczęściej wyglądają tak:

W dużym zestawie niezależnych testów Playwright zwykle łatwiej wykorzystuje wiele rdzeni bez dodatkowej usługi. To nadal nie gwarantuje krótszego czasu całego pipeline'u. Wąskim gardłem może być baza danych, budowanie Next.js albo zbyt mała liczba runnerów CI.

Wsparcie dla Next.js: Cypress vs Playwright

SSR w Next.js a testy E2E

Oba narzędzia otwierają dokument wygenerowany przez Next.js i pozwalają sprawdzić efekt renderowania serwerowego. Nie oznacza to jednak, że page.route() lub cy.intercept() przechwyci fetch() wykonany wewnątrz Server Componentu. Te mechanizmy obserwują ruch wychodzący z przeglądarki, a zapytanie komponentu serwerowego powstaje w procesie Next.js.

Jeżeli chcesz zweryfikować metadane zwrócone dla trasy, sprawdź wynik nawigacji i elementy dokumentu zamiast szukać fragmentu surowego HTML:

import { test, expect } from '@playwright/test'
 
test('SSR page exposes Open Graph metadata', async ({ page }) => {
  const response = await page.goto('/blog/my-post')
 
  expect(response?.status()).toBe(200)
  await expect(page.locator('meta[property="og:title"]')).toHaveAttribute(
    'content',
    /.+/,
  )
})

Gdy zależy Ci na kontrolowaniu danych pobieranych przez Server Component, przygotuj testowy backend, bazę lub warstwę zależności uruchamianą po stronie serwera. Mock przeglądarkowy nie zastąpi takiego środowiska.

App Router i Server Components w testach E2E

Next.js App Router z React Server Components wprowadza dodatkowe wyzwania: streaming, przejścia między trasami, cache, loading UI oraz granice między kodem serwera i klienta. Z punktu widzenia E2E oba frameworki obserwują jednak tę samą publiczną powierzchnię aplikacji: odpowiedź HTTP, DOM i zachowanie w przeglądarce.

Dla asynchronicznych Server Components dokumentacja Next.js zaleca testy E2E zamiast prób izolowanego montowania komponentu. Nie daje to automatycznej przewagi Cypressowi ani Playwrightowi. Różnica wynika przede wszystkim z ergonomii runnera, obsługiwanych silników i sposobu skalowania CI.

Next.js i Playwright — oficjalne wsparcie i przykłady

Next.js publikuje oficjalne przewodniki zarówno dla Playwright, jak i Cypress. Sam fakt obecności przykładu nie jest rekomendacją jednego narzędzia ponad drugim.

W konfiguracji Playwright warto jawnie określić zachowanie lokalne i CI. Poniższy wariant uruchamia szybki serwer deweloperski lokalnie, a w CI zakłada wcześniejsze wykonanie npm run build i testuje aplikację przez next start:

// playwright.config.ts
import { defineConfig } from '@playwright/test'
 
export default defineConfig({
  webServer: {
    command: process.env.CI ? 'npm run start' : 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
  },
  retries: process.env.CI ? 2 : 0,
})

Taki podział ma znaczenie. next dev i produkcyjny build mogą inaczej zachowywać się w obszarze cache, optymalizacji zasobów i obsługi błędów.

Component testing w Cypress i Playwright

Cypress Component Testing w projektach React i Next.js

Cypress oferuje dedykowany Component Testing runner oraz konfigurację framework: 'next'. Renderuje komponent w prawdziwej przeglądarce bez uruchamiania całej aplikacji Next.js.

// cypress/component/Button.cy.tsx
import { Button } from '@/components/Button'
 
describe('Button', () => {
  it('calls the click handler', () => {
    const onClick = cy.stub().as('clickHandler')
 
    cy.mount(<Button onClick={onClick}>Wyślij</Button>)
    cy.contains('button', 'Wyślij').click()
    cy.get('@clickHandler').should('have.been.calledOnce')
  })
})

Ta integracja ma granice. Cypress nie montuje obecnie komponentów serwerowych oznaczonych async, a funkcje wymagające działającego serwera Next.js, takie jak część zachowań next/image, mogą wymagać mocków albo testu E2E.

Playwright Component Testing i galeria komponentów

Playwright Component Testing nie jest już funkcją eksperymentalną. Stabilny model wykorzystuje zwykły @playwright/test, fixture mount() i małą galerię scenariuszy komponentów obsługiwaną przez serwer należący do projektu.

Playwright nie przejmuje bundlera ani konfiguracji Next.js. Z jednej strony ogranicza to problemy z aliasami, CSS i niestandardowym buildem. Z drugiej wymaga utrzymania galerii oraz plików *.story.tsx, więc Cypress nadal oferuje bardziej bezpośredni start dla Component Testing w Next.js.

Nie ma więc bezwarunkowego zwycięzcy tej kategorii. Cypress wygrywa gotową integracją z frameworkiem, a Playwright spójnym runnerem i możliwością testowania komponentów przez ten sam zestaw fixture'ów, retry, trace'ów i workerów co E2E.

Wsparcie przeglądarek: Chrome, Firefox, WebKit i Safari

Określenie „testy Safari” jest skrótem myślowym. Playwright korzysta z WebKit z własnymi patchami, często nowszego niż silnik wydany w aktualnym Safari. Cypress eksperymentalnie uruchamia ten sam pakiet playwright-webkit. Do wykrywania wielu problemów zgodności to wartościowe pokrycie, ale krytyczne ścieżki dla użytkowników Apple nadal warto sprawdzić na prawdziwym Safari lub urządzeniu.

Podobnie działa emulacja mobilna. Zmiana viewportu, user agenta i obsługi dotyku nie odtwarza systemowego Safari, ograniczeń sprzętu ani wszystkich zachowań iOS.

CI/CD i raportowanie testów E2E

Cypress w CI/CD i Cypress Cloud

• Open-source runner jest darmowy,
• Cypress Cloud jest opcjonalny i rozliczany według planu; oferuje między innymi historię, analytics, Test Replay oraz dynamiczne balansowanie speców,
• screenshoty i lokalne materiały z przebiegu nie wymagają Cloud, ale platforma ułatwia ich powiązanie z testami i historią uruchomień,
• bez Cloud można uruchamiać osobne, statycznie podzielone joby CI, lecz podział i łączenie raportów trzeba utrzymać samodzielnie.

Playwright w CI/CD, trace viewer i paralelizacja

• Wbudowane raportowanie HTML,
• Trace Viewer do analizy DOM, requestów i kolejnych kroków testu,
• workery na jednej maszynie oraz --shard=x/y do podziału zestawu między joby,
• brak obowiązkowej usługi SaaS; płacisz jednak za maszyny CI i przechowywanie raportów.

# .github/workflows/e2e.yml - Playwright
- name: Build Next.js
  run: npm run build
- name: Install Playwright browsers
  run: npx playwright install --with-deps
- name: Run Playwright tests
  run: npx playwright test
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/

Kiedy wybrać Cypress do projektu Next.js?

• Twój zespół ceni najlepsze doświadczenie deweloperskie i interaktywne debugowanie.

• Chcesz gotowej integracji Component Testing z Next.js.

• Testujecie głównie Chrome, Firefox lub Edge, a eksperymentalny WebKit wystarcza jako dodatkowy sygnał.

• Masz już zespół obeznany z komendami Cypress i nie chcesz komplikować workflow.

• Masz budżet na Cypress Cloud albo nie potrzebujesz wykorzystywać agresywnej paralelizacji w CI.

Kiedy wybrać Playwright do projektu Next.js?

• Potrzebujesz stabilnych testów na wielu silnikach, w tym Chromium, Firefox i WebKit.

• Szybkość CI jest priorytetem (Playwright ma natywną paralelizację).

• Chcesz używać jednego runnera do testów UI, API i pełnych ścieżek E2E.

• Chcesz skalować testy przez workery i sharding bez obowiązkowej usługi SaaS.

• Preferujesz natywne async/await.

Cypress czy Playwright dla Next.js w 2026 — rekomendacja

Dla nowego projektu Next.js zacząłbym zwykle od Playwrighta, gdy głównym celem jest E2E. Przemawiają za nim stabilne pokrycie Chromium, Firefoksa i WebKit, wbudowane workery, sharding oraz artefakty diagnostyczne bez obowiązkowej platformy SaaS.

Cypress jest równie racjonalnym wyborem, jeśli zespół już sprawnie się nim posługuje, dużo czasu spędza w interaktywnym runnerze albo chce bezpośredniej integracji Component Testing z Next.js. Migracja działającego zestawu tylko ze względu na popularność drugiego narzędzia rzadko się zwróci.

Przed ostateczną decyzją przygotuj po dwa lub trzy reprezentatywne scenariusze w obu narzędziach: logowanie, ścieżkę z Server Action oraz przepływ zależny od danych. Uruchom je kilkadziesiąt razy lokalnie i w CI. Porównaj nie tylko czas, ale też liczbę niestabilnych przebiegów, jakość diagnostyki i nakład potrzebny do przygotowania danych.