Playwright vs Cypress vs Selenium: Der ehrliche Vergleich für 2026

Playwright hat Cypress bei den wöchentlichen npm-Downloads Mitte 2024 überholt, und Anfang 2026 ist der Abstand auf rund 30 Millionen gegenüber 6,5 Millionen wöchentliche Downloads angewachsen. Das ist kein Zufall. Jeder andere Vergleich auf Googles erster Seite wird von einem QA-Tool-Anbieter oder Testing-SaaS-Unternehmen geschrieben. Dieser hier stammt von einem Team, das produktive Webanwendungen baut und Test-Automatisierungsframeworks für echte Projekte auswählt -- nicht um ein Produkt zu bewerben.

So passt Selenium ins Bild: Es ist immer noch das weltweit am weitesten verbreitete E2E-Framework, besonders in Java- und Python-Teams. Es geht nirgendwo hin. Aber für neue JavaScript/TypeScript-Projekte in 2026 lautet die eigentliche Frage Playwright vs. Cypress -- mit Selenium als Legacy-Fallback.

Auf einen Blick -- Schnellübersicht

Playwright wählen, wenn Sie das beste Test-Framework für 2026 wollen: schnellste Ausführung, kostenlose Parallelisierung, mehrsprachige Unterstützung und exzellentes TypeScript-DX. Cypress wählen, wenn Ihr Team interaktives Debugging und Component-Testing über alles andere stellt. Selenium wählen, wenn Sie sich in einer Java/Python-Unternehmensumgebung mit bestehender Selenium-Infrastruktur befinden.

Das ist die Zusammenfassung. Der Rest dieses Artikels erklärt die Belege hinter jeder Zeile -- mit Code, Benchmarks und ehrlichen Meinungen.

Architektur -- Wie jedes Tool mit dem Browser kommuniziert

Die Architektur ist die eigentliche Ursache fast jedes Unterschieds, den Sie in diesem Vergleich sehen werden. Stellen Sie es sich so vor: Playwright spricht mit dem Browser wie ein Regisseur, der Anweisungen direkt an die Schauspieler flüstert. Cypress sitzt auf der Bühne mit den Schauspielern und läuft im gleichen Raum. Selenium schickt Anweisungen durch einen Mittelsmann, der auf dem Flur steht.

Playwright: Direkte Browser-Steuerung via WebSocket

Playwright kommuniziert mit Browsern über WebSocket-Verbindungen und verwendet das Chrome DevTools Protocol (CDP) für Chromium sowie äquivalente Protokolle für Firefox und WebKit. Es gibt keinen Vermittler -- Ihr Testcode sendet Befehle direkt an die Browser-Engine. Das bedeutet niedrigere Latenz, mehr Fähigkeiten (Multi-Tab, Multi-Origin, Netzwerk-Abfangung) und weniger bewegliche Teile, die kaputt gehen können.

Cypress: Ausführung im Browser

Cypress verfolgt einen grundlegend anderen Ansatz. Es injiziert sich in den Browser und führt Ihren Testcode im gleichen JavaScript-Event-Loop wie Ihre Anwendung aus. Deshalb fühlt sich Cypress für einfache Tests so schnell an -- es gibt keinerlei Netzwerkoverhead zwischen Ihrem Test und der App. Aber diese Architektur erklärt auch die Einschränkungen von Cypress: keine Multi-Tab-Unterstützung, eingeschränktes Cross-Origin-Testing und nur JavaScript/TypeScript (da die Tests im Browser-Kontext laufen müssen).

Selenium: Der WebDriver-Vermittler

Selenium verwendet das WebDriver-Protokoll. Ihr Testcode sendet HTTP-Anfragen an eine Browser-Treiber-Binärdatei (chromedriver, geckodriver), die diese Anfragen in Browser-Befehle übersetzt. Jeder Befehl ist ein Hin- und Rückweg: Test zu Treiber zu Browser und zurück. Diese Indirektion erhöht die Latenz und schafft mehr Fehlerpunkte. Selenium übernimmt schrittweise das BiDi-Protokoll, um diesen Overhead zu reduzieren, ist aber noch nicht vollständig dort.

Fazit: Playwright gewinnt in der Architektur. Direkte WebSocket-Kommunikation bedeutet schnellere Ausführung, mehr Fähigkeiten und weniger flüchtige Fehler. Cypress' In-Browser-Modell ist für einfache Single-Origin-Tests wirklich clever, aber es schafft harte Grenzen, die Playwright nicht hat. Seleniums Architektur zeigt ihr Alter.

Sprach- und Browser-Unterstützung

Dies ist oft der erste Filter. Wenn Ihr Team kein JavaScript schreibt, scheidet Cypress sofort aus.

Was bedeutet das in der Praxis? Wenn Sie ein Java-Shop mit 20 QA-Ingenieuren sind, ist Cypress keine Option -- Punkt. Wenn plattformübergreifendes Testen einschließlich Safari wichtig ist (und das sollte es -- Safari hat etwa 18% des globalen Browser-Marktanteils), verarbeitet Playwright es auf jedem Betriebssystem, während Cypress die WebKit-Unterstützung immer noch als "experimentell" kennzeichnet.

Selenium gewinnt an roher Breite. Es unterstützt mehr Sprachen und mehr Browser als beide Alternativen. Aber für die Sprachen und Browser, die 2026 am meisten zählen -- JavaScript/TypeScript, Python und das Chromium/Firefox/WebKit-Trio -- deckt Playwright alles mit null Konfiguration und gebündelten Browser-Binärdateien ab.

Fazit: Selenium gewinnt an Breite (die meisten Sprachen, die meisten Browser, einschließlich IE). Playwright gewinnt bei praktischer Abdeckung -- die Browser und Sprachen, die 2026 wichtig sind, gebündelt und ohne Konfiguration. Cypress ist die eingeschränkteste Option.

Tests schreiben -- Code-Vergleich Seite an Seite

Genug Theorie. Hier ist derselbe Test in allen drei Frameworks geschrieben. Hier spüren Sie den DX-Unterschied.

Login-Flow-Test

Ein Standard-Login-Test: Navigieren zu einer Seite, Anmeldedaten eingeben, absenden und die Weiterleitung überprüfen.

// Playwright
import { test, expect } from '@playwright/test';

test('user can log in', async ({ page }) => {
  await page.goto('/login');
  await page.locator('#email').fill('[email protected]');
  await page.locator('#password').fill('s3cureP@ss');
  await page.locator('button[type="submit"]').click();
  await expect(page).toHaveURL('/dashboard');
  await expect(page.locator('h1')).toContainText('Welcome');
});

// Cypress
describe('Login', () => {
  it('user can log in', () => {
    cy.visit('/login');
    cy.get('#email').type('[email protected]');
    cy.get('#password').type('s3cureP@ss');
    cy.get('button[type="submit"]').click();
    cy.url().should('include', '/dashboard');
    cy.get('h1').should('contain', 'Welcome');
  });
});

// Selenium (with WebDriver)
const { Builder, By, until } = require('selenium-webdriver');

describe('Login', function () {
  let driver;

  before(async () => {
    driver = await new Builder().forBrowser('chrome').build();
  });

  after(async () => {
    await driver.quit();
  });

  it('user can log in', async () => {
    await driver.get('http://localhost:3000/login');
    await driver.findElement(By.id('email')).sendKeys('[email protected]');
    await driver.findElement(By.id('password')).sendKeys('s3cureP@ss');
    await driver.findElement(By.css('button[type="submit"]')).click();
    await driver.wait(until.urlContains('/dashboard'), 5000);
    const heading = await driver.findElement(By.css('h1')).getText();
    expect(heading).to.include('Welcome');
  });
});

Beachten Sie die Unterschiede. Playwrights async/await mit page.locator() liest sich sauber und wartet automatisch, bis Elemente aktionierbar sind, bevor sie damit interagiert. Cypress' Verkettungs-API (cy.get().type().click()) ist prägnant und für einfache Abläufe wirklich angenehm. Selenium erfordert explizite Wartezeiten (driver.wait(until.urlContains(...))), manuelle Browser-Lifecycle-Verwaltung und mehr Boilerplate.

API-Mocking und Netzwerk-Abfangung

Dieses Szenario offenbart einen viel größeren Unterschied. Einen API-Aufruf abfangen, Mock-Daten zurückgeben und überprüfen, ob die UI korrekt rendert.

// Playwright -- native network interception
test('shows mocked user list', async ({ page }) => {
  await page.route('**/api/users', (route) => {
    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify([{ id: 1, name: 'Alice' }]),
    });
  });
  await page.goto('/users');
  await expect(page.locator('.user-card')).toHaveCount(1);
  await expect(page.locator('.user-card')).toContainText('Alice');
});

// Cypress -- native network interception
it('shows mocked user list', () => {
  cy.intercept('GET', '/api/users', {
    statusCode: 200,
    body: [{ id: 1, name: 'Alice' }],
  }).as('getUsers');
  cy.visit('/users');
  cy.wait('@getUsers');
  cy.get('.user-card').should('have.length', 1);
  cy.get('.user-card').should('contain', 'Alice');
});

// Selenium -- no native network interception
// You need a separate proxy tool like BrowserMob Proxy
// or mock your API server directly. There is no built-in
// equivalent to page.route() or cy.intercept().

// Typical workaround: start a mock server before the test
const mockServer = require('./helpers/mock-server');

before(async () => {
  await mockServer.start({ port: 4000 });
  mockServer.stub('GET', '/api/users', [{ id: 1, name: 'Alice' }]);
});

it('shows mocked user list', async () => {
  await driver.get('http://localhost:3000/users');
  // ... assert using findElement
});

Das ist bedeutsam. API-Mocking ist für zuverlässige E2E-Tests unerlässlich, und sowohl Playwright als auch Cypress handhaben es nativ. Selenium erfordert einen separaten Mock-Server oder ein Proxy-Tool -- mehr Infrastruktur, mehr Komplexität, mehr Dinge, die kaputtgehen können.

Fazit: Playwright gewinnt bei Code-Klarheit und Leistungsfähigkeit. Seine async/await-Syntax ist für komplexe Szenarien klarer als Cypress' Verkettung, und es verarbeitet API-Mocking, Multi-Tab und Multi-Origin nativ. Cypress gewinnt bei der Einfachheit für geradlinige Single-Page-Abläufe -- die Verkettungs-API ist wirklich angenehm. Selenium ist am ausführlichsten und erfordert den meisten Boilerplate.

Playwright vs. Cypress vs. Selenium: Geschwindigkeits-Benchmarks

"Was ist schneller?" ist eine der am häufigsten gesuchten Fragen in diesem Vergleich. Hier sind tatsächliche Zahlen aus Checklys Benchmark-Studie und BetterStacks Messungen, für Konsistenz gegengeprüft.

Playwright beendet äquivalente Test-Suites in rund 4,5 Sekunden, verglichen mit 9,4 Sekunden für Cypress und 14,5 Sekunden für Selenium. Das ist kein marginaler Unterschied -- es ist ein 2x- und 3x-Abstand.

Warum ist Playwright schneller? Drei Gründe: WebSocket-Kommunikation eliminiert den HTTP-Overhead, den Selenium trägt. Playwrights Browser-Kontext-Modell erstellt isolierte Test-Umgebungen, ohne ganze Browser-Prozesse zu starten. Und seine parallele Ausführung erfolgt auf Framework-Ebene -- Sie brauchen keine externen Tools.

Der Geschwindigkeitsabstand wächst mit größeren Test-Suites. Playwrights Browser-Kontexte skalieren effizient, weil sie einen einzigen Browser-Prozess teilen. Selenium startet neue Browser-Instanzen pro parallelem Worker. Cypress läuft Tests in seiner Open-Source-Version seriell, sodass eine wachsende Suite lineare Ausführungszeit bedeutet, es sei denn, Sie zahlen für Cypress Cloud.

Eine Migrations-Fallstudie versieht dies mit Zahlen: BigBinary berichtete von einer 89%igen Reduktion der Testausführungszeit nach dem Wechsel von Cypress zu Playwright -- ihre vollständige Suite fiel von 2 Stunden 27 Minuten auf 16 Minuten mit Playwrights Sharding.

Fazit: Playwright gewinnt entscheidend bei Geschwindigkeit. Es läuft Test-Suites 2x schneller als Cypress und 3x schneller als Selenium. Dieser Abstand wächst mit größeren Suites, weil Playwrights Browser-Kontext-Modell besser skaliert als das Starten neuer Browser-Instanzen.

Debugging und Developer Experience

Hier wird es nuanciert. Playwright ist technisch überlegen, aber Cypress hat einen echten DX-Vorteil, der Teams loyal hält.

Interaktives Debugging

Cypress Test Runner ist nach wie vor der Goldstandard für interaktives Debugging. Sie sehen, wie Ihr Test in Echtzeit in einem echten Browser ausgeführt wird, mit Time-Travel-Debugging -- klicken Sie auf jeden Schritt im Command Log, um den genauen DOM-Zustand in diesem Moment zu sehen. Für Frontend-Entwickler, die visuelle Regressionen oder Layout-Probleme debuggen, ist das schwer zu schlagen. Ehrlich gesagt ist es das einzige beste Feature im gesamten Toolkit von Cypress.

Playwright Trace Viewer verfolgt einen anderen Ansatz. Es zeichnet Traces während der Testläufe auf -- Screenshots, DOM-Snapshots, Netzwerkanfragen und Konsolen-Logs bei jedem Schritt. Sie öffnen diese Traces nach dem Faktum in einem browserbasierten Viewer. Für das CI-Debugging (Herausfinden, warum ein Test in einer Headless-Pipeline fehlgeschlagen ist), ist Trace Viewer tatsächlich nützlicher als Cypress' interaktiver Runner, weil Sie den vollständigen Kontext ohne lokale Reproduktion erhalten.

Playwrights --ui-Modus hat in neueren Versionen eine interaktivere Erfahrung hinzugefügt, die Cypress' Test Runner näher kommt, aber er ist nicht so poliert. Er ist funktional, nicht erfreulich.

Selenium IDE existiert, ist aber begrenzt. Das meiste Selenium-Debugging ist console.log und Screenshots. Es funktioniert, fühlt sich aber wie 2012 an.

TypeScript-First-Entwicklung

Playwright ist TypeScript-first. Es wird mit automatisch generierten Typen geliefert, seine Konfigurationsdatei ist standardmäßig playwright.config.ts, und VS Code Autocomplete funktioniert tadellos. Wenn Sie page. tippen und Autocomplete drücken, erhalten Sie jede Methode mit vollständigen Typsignaturen.

Cypress unterstützt TypeScript, aber es gibt Reibungspunkte. Benutzerdefinierte Befehle benötigen manuelle Typ-Deklarationen (die Cypress.Chainable-Interface-Erweiterung), und die Verkettungs-API verwirrt manchmal die TypeScript-Inferenz. Die cypress.config.ts-Datei funktioniert, aber das DX ist nicht so nahtlos.

Seleniüms TypeScript-Unterstützung ist eine Community-Bemühung und fühlt sich im Vergleich zu Playwrights nativer Erfahrung aufgesetzt an.

Fazit: Cypress gewinnt beim interaktiven DX -- sein Test Runner ist für Frontend-Entwickler, die visuelle Tests debuggen, wirklich erfreulich. Playwright gewinnt beim CI-Debugging und TypeScript -- Trace Viewer ist speziell für die Diagnose von Fehlern in Headless-CI-Umgebungen konzipiert, und seine TypeScript-Unterstützung ist erstklassig. Seleniüms Debugging-Geschichte ist die schwächste.

CI/CD-Integration und Parallelisierung

Hier trifft die Gummi auf die Straße. Ihre Test-Suite läuft täglich hunderte Male in CI, nicht auf Ihrem Laptop. Hier ist eine Copy-Paste-GitHub-Actions-Konfiguration für jedes Framework -- etwas, das kein Mitbewerber auf der ersten Google-Seite bietet.

GitHub Actions Konfiguration

# Playwright -- built-in parallelization, zero cost
name: Playwright Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1/4, 2/4, 3/4, 4/4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report-${{ matrix.shard }}
          path: playwright-report/

# Cypress -- parallel requires Cypress Cloud (paid)
name: Cypress Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        containers: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: cypress-io/github-action@v6
        with:
          record: true
          parallel: true
          group: 'CI'
        env:
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

# Selenium -- requires browser service container
name: Selenium Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      selenium:
        image: selenium/standalone-chrome:latest
        ports:
          - 4444:4444
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test
        env:
          SELENIUM_REMOTE_URL: http://localhost:4444/wd/hub

Parallelisierung: Kostenlos vs. Kostenpflichtig

Die Playwright-Konfiguration oben teilt Ihre Test-Suite mit --shard=1/4 auf 4 parallele Shards auf. Eine 10-minütige Suite läuft in 2,5 Minuten. Null Kosten. Kein Cloud-Service erforderlich.

Cypress' kostenloses Starter-Plan beinhaltet jetzt Parallelisierung, aber mit einem Limit von 500 Testergebnissen/Monat -- das die meisten Teams in einem Tag oder zwei aktiver Entwicklung aufbrauchen. Für ernsthaften CI-Einsatz benötigen Sie Cypress Cloud (ab €62/Monat bei Jahresabrechnung für den Team-Plan mit 120.000 Ergebnissen/Jahr) oder Community-Alternativen wie sorry-cypress. Die record: true und parallel: true Flags im YAML oben erfordern eine Cypress Cloud-Verbindung.

Die Selenium-Parallelisierung erfordert Selenium Grid (selbst gehostet, Betriebsoverhead) oder einen Cloud-Anbieter wie BrowserStack. Es ist die komplexeste Einrichtung der drei.

Fazit: Playwright gewinnt bei CI/CD. Kostenlose, unbegrenzte Parallelisierung ohne Infrastruktur ist schwer zu schlagen. Cypress' kostenloser Plan beinhaltet Parallelisierung, ist aber auf 500 Ergebnisse/Monat begrenzt -- echte Teams benötigen einen bezahlten Plan. Selenium erfordert den meisten Betriebsaufwand.

Kosten- und Preisanalyse

Dies ist die größte Inhaltslücke im gesamten SERP für dieses Keyword. Jeder Mitbewerber überspringt es, aber Kosten sind wichtig -- besonders im größeren Maßstab.

Lizenzierung und Preisstufen

Reale Kosten nach Teamgröße

Playwright ist für alles kostenlos, wofür Cypress Gebühren erhebt. Parallelisierung, Test-Analytik via HTML-Reporter, Trace Viewer für Debugging, Codegen für Test-Gerüste -- alles kostenlos inklusive. Das Einzige, was Playwright nicht bietet, ist ein gehostetes Cloud-Dashboard mit Team-Kollaborationsfunktionen, und für viele Teams sind der eingebaute HTML-Bericht und CI-Artefakte ausreichend.

Selenium ist ebenfalls kostenlos, aber die Infrastrukturkosten für den Betrieb von Selenium Grid im größeren Maßstab sind nicht trivial. Jemand in Ihrem Team muss diese Grid-Knoten warten, Browser-Versionsaktualisierungen handhaben und Infrastrukturausfälle debuggen.

Fazit: Playwright gewinnt bei den Kosten -- es ist nicht einmal knapp. Jede Funktion, die Cypress hinter einer Zahlungsschranke versteckt (Parallelisierung, Test-Analytik, Flake-Erkennung), bietet Playwright kostenlos an. Selenium ist auf Tool-Ebene kostenlos, aber die Infrastrukturrechnung summiert sich.

Component Testing

Component Testing ermöglicht es Ihnen, eine einzelne React-, Vue- oder Angular-Komponente isoliert zu mounten und zu testen, ohne eine vollständige Anwendung zu starten. Cypress hat diesen Ansatz pioniert, und es ist einer der stärksten Gründe, heute Cypress zu wählen.

Cypress hat erstklassiges Component Testing für React (18-19), Vue 3, Angular (18-21) und Svelte 5. Sie verwenden dieselbe cy.mount()-API und denselben Test Runner, den Sie bereits von E2E-Tests kennen. Die Dokumentation ist ausgereift, das Ökosystem ist solide, und es funktioniert zuverlässig. Für Teams, die ein einziges Tool sowohl für Component- als auch E2E-Testing wollen, ist Cypress' Component Testing ein echter Differenziator.

Playwright hat in neueren Versionen experimentelles Component Testing hinzugefügt, das React, Vue und Svelte unterstützt. Es ist funktional, aber weniger poliert als Cypress' Implementierung. Wenn Component Testing ein Tages-1-Priorität ist, hat Cypress die Nase vorn. Aber Playwrights schneller Release-Takt (monatlich) bedeutet, dass dieser Abstand sich schließt.

Selenium hat keine Component-Testing-Unterstützung. Es operiert auf Browser-Ebene, nicht auf Komponenten-Ebene. Wenn Sie Component Testing neben Selenium E2E-Tests benötigen, verwenden Sie ein separates Tool wie React Testing Library oder Vitest.

Fazit: Cypress gewinnt beim Component Testing -- es hat den Ansatz pioniert, hat die ausgereifteste Implementierung und deckt die breiteste Palette von Frameworks ab. Playwright ist ein starker Zweiter. Selenium ist hier kein Mitbewerber.

Community, Ökosystem und Adoptionstrends

Zahlen erzählen hier eine Geschichte. Playwright hat Cypress bei npm-Downloads Mitte 2024 überholt, und bis Februar 2026 ist der Abstand erheblich: Playwright zieht rund 30 Millionen wöchentliche Downloads gegenüber Cypress' 6,5 Millionen und Selenium WebDrivers 1,8 Millionen.

GitHub-Stars folgen einem ähnlichen Muster: Playwright liegt bei rund 82.800, Cypress bei 49.461 und Selenium bei 33.769 (Stand Februar 2026). Die State of JavaScript-Umfrage bewertet Playwright konsequent am höchsten in Entwicklerzufriedenheit und -interesse.

Aber npm erzählt nur die JavaScript-Geschichte. Seleniums echte installierte Basis umfasst Java-, Python-, C#- und Ruby-Ökosysteme, wo npm-Downloads nicht zutreffen. In der Java-Unternehmenswelt ist Selenium immer noch das dominante Framework mit großem Vorsprung.

Warum wächst Playwright so schnell? Microsofts Unterstützung sorgt für konsistente monatliche Releases und langfristige Stabilität. TypeScript-first-Design passt zu der Richtung, in die die Frontend-Entwicklung geht. Kostenlose Parallelisierung beseitigt die Reibung, die Cypress Cloud-Preise verursachen. Und mehrsprachige Unterstützung bedeutet, dass Python- und Java-Teams von Selenium migrieren können, ohne die Sprache zu wechseln.

Cypress schrumpft in absoluten Zahlen nicht -- Downloads haben sich bei etwa 6-7 Millionen wöchentlich eingependelt. Aber sein relativer Anteil schrumpft, da Playwright sowohl neue Projekte als auch Cypress/Selenium-Migrationen absorbiert.

Fazit: Playwright gewinnt beim Schwung. Es hat das schnellste Wachstum, die höchste Entwicklerzufriedenheit und die stärkste Trajektorie. Selenium gewinnt bei der installierten Basis. Cypress behält eine treue Community, aber sein Wachstum hat sich eingependelt.

Migrationsleitfaden -- Framework-Wechsel

Wenn Sie einen Wechsel in Betracht ziehen, ist hier der praktische Übersetzungsleitfaden.

Von Cypress zu Playwright: API-Übersetzung

// BEFORE: Cypress login test
describe('Login', () => {
  it('logs in successfully', () => {
    cy.visit('/login');
    cy.get('#email').type('[email protected]');
    cy.get('#password').type('password123');
    cy.get('form').submit();
    cy.url().should('include', '/dashboard');
  });
});

// AFTER: Same test in Playwright
import { test, expect } from '@playwright/test';

test('logs in successfully', async ({ page }) => {
  await page.goto('/login');
  await page.locator('#email').fill('[email protected]');
  await page.locator('#password').fill('password123');
  await page.locator('form').evaluate(form => form.submit());
  await expect(page).toHaveURL(/dashboard/);
});

Schlüsselübersetzungen: cy.visit() wird zu page.goto(). cy.get() wird zu page.locator(). cy.intercept() wird zu page.route(). cy.wait('@alias') wird zu page.waitForResponse(). Cypress' implizite Verkettung wird zu explizitem async/await.

Von Selenium zu Playwright: API-Übersetzung

// BEFORE: Selenium login test
const { Builder, By, until } = require('selenium-webdriver');

async function loginTest() {
  const driver = await new Builder().forBrowser('chrome').build();
  try {
    await driver.get('http://localhost:3000/login');
    await driver.findElement(By.id('email')).sendKeys('[email protected]');
    await driver.findElement(By.id('password')).sendKeys('password123');
    await driver.findElement(By.css('form')).submit();
    await driver.wait(until.urlContains('/dashboard'), 10000);
  } finally {
    await driver.quit();
  }
}

// AFTER: Same test in Playwright
import { test, expect } from '@playwright/test';

test('logs in successfully', async ({ page }) => {
  await page.goto('/login');
  await page.locator('#email').fill('[email protected]');
  await page.locator('#password').fill('password123');
  await page.locator('form').evaluate(form => form.submit());
  await expect(page).toHaveURL(/dashboard/);
});

Der größte Unterschied? Playwright verwaltet Browser-Lifecycle und Auto-Waiting für Sie. Keine driver.quit() mehr in finally-Blöcken. Kein driver.wait(until.urlContains(...), 10000) mehr -- Playwright wartet automatisch auf Navigation. Entfernen Sie alle Ihre impliziten und expliziten Wartezeiten; Playwrights Auto-Waiting ersetzt sie.

Migrations-Checkliste

1. Prüfen Sie Ihre bestehende Test-Suite -- zählen Sie Tests, identifizieren Sie benutzerdefinierte Befehle (Cypress) oder komplexe Wait-Logik (Selenium)
2. Installieren Sie Playwright neben Ihrem aktuellen Framework -- führen Sie beide während des Übergangs in CI aus
3. Übersetzen Sie Tests schrittweise -- beginnen Sie mit den einfachsten, wertvollsten Tests
4. Ersetzen Sie benutzerdefinierte Befehle durch Page Objects oder Fixtures -- Cypress-Benutzerbefehle haben kein 1:1-Playwright-Äquivalent
5. Aktualisieren Sie Ihre CI-Konfiguration -- fügen Sie Playwrights Sharding-Konfiguration hinzu, entfernen Sie ggf. Cypress Cloud-Schlüssel
6. Führen Sie beide Frameworks parallel für 1-2 Sprints aus, um Regressionen zu erkennen
7. Deprecieren Sie das alte Framework, sobald alle Tests migriert und stabil sind

Eine typische 200-Test-Cypress-Suite kann in 1-2 Sprints von einem Ingenieur migriert werden. Die Selenium-zu-Playwright-Migration dauert etwas länger, weil Selenium-Tests tendenziell komplexere Wait-Logik haben, die überarbeitet werden muss. Wenn Sie migrieren, ist Playwright das Ziel, das 90% der Teams in 2026 wählen. Die Migration selbst ist unkompliziert -- der schwierigste Teil sind in der Regel benutzerdefinierte Cypress-Befehle oder komplexe Selenium-Wait-Logik.

Stack-spezifische Empfehlungen -- React, Next.js und mehr

Generische "es kommt darauf an"-Ratschläge sind nutzlos. Hier ist, was wir für spezifische Tech-Stacks auswählen würden, basierend auf dem Aufbau von Produktionsanwendungen mit diesen Frameworks.

Wenn Ihr Team mit Next.js baut und Frameworks bewertet, deckt unser Next.js vs. Remix-Vergleich ab, wie Framework-Architektur Ihre Testing-Strategie beeinflusst. Playwrights Fähigkeit, API-Routen und Server-Komponenten nativ zu testen, macht es besonders leistungsfähig im Next.js-Ökosystem.

KI-unterstütztes Testing in 2026

KI-unterstütztes Testing ist nicht mehr hypothetisch -- Tools wie GitHub Copilot, Cursor und Claude Code generieren täglich Testcode für Tausende von Entwicklern. Die Framework-Wahl beeinflusst, wie gut diese Tools funktionieren.

Playwright hat die beste KI-Kompatibilität. Seine TypeScript-first-API mit starken Typdefinitionen bedeutet, dass KI-Assistenten präziseren Testcode generieren. Die strukturierten async/await-Muster sind für LLMs einfacher zu verstehen als Cypress' Verkettung. Und Playwrights eigenes npx playwright codegen-Tool zeichnet Browser-Interaktionen auf und generiert vollständige Testdateien mit intelligenter Locator-Auswahl -- kein KI-Abonnement erforderlich.

Cypress funktioniert vernünftig gut mit KI-Tools. Seine deklarative Verkettungs-API ist prägnant und gut in Trainingsdaten vertreten. Aber der cy.-Namensraum und benutzerdefinierte Befehlsmuster können Code-Generierung stolpern lassen und Tests produzieren, die korrekt aussehen, aber aufgrund Cypress-spezifischer Eigenheiten fehlschlagen.

Selenium passt am schlechtesten zum KI-unterstützten Testing. Ausführliches Boilerplate, mehrere Sprachbindings mit unterschiedlichen APIs und inkonsistente Muster über Java/Python/JS hinweg bedeuten, dass KI-generierter Selenium-Code die meiste manuelle Bereinigung erfordert.

Überschätzen Sie die Rolle der KI nicht hier -- es ist ein Produktivitätsmultiplikator, kein Ersatz für Test-Design. Aber wenn Ihr Team KI-Coding-Assistenten verwendet (und die meisten tun es in 2026), produziert Playwright die zuverlässigsten generierten Tests.

Fazit: Playwright gewinnt bei der KI-unterstützten Test-Generierung. Seine typisierte API und strukturierten Muster liefern die besten Ergebnisse mit modernen KI-Coding-Assistenten.

Entscheidungsrahmen -- Welches Tool sollten Sie wählen?

Hier ist der Abschnitt, auf den Sie gewartet haben. Konkrete Szenarien, konkrete Empfehlungen.

Wann Sie jedes Tool NICHT verwenden sollten

• Wählen Sie Playwright nicht, wenn Ihr gesamtes Team Cypress tief kennt, umfangreiche benutzerdefinierte Befehle hat und keine Schmerzpunkte hat. Migrationskosten existieren, und "neuer" bedeutet nicht "besser für Ihre Situation."
• Wählen Sie Cypress nicht, wenn Sie mehrsprachige Unterstützung, Multi-Tab-Testing oder kostenlose parallele Ausführung im großen Maßstab benötigen. Das sind Architektureinschränkungen, keine Features auf einer Roadmap.
• Wählen Sie Selenium nicht für neue JavaScript/TypeScript-Projekte. Sowohl Playwright als auch Cypress bieten für JS-Teams dramatisch besseres DX, Geschwindigkeit und Zuverlässigkeit.

Wie Techsy an Test-Automatisierung herangeht

Bei Techsy haben wir E2E-Testing in Dutzenden von Produktionswebanwendungen implementiert. Hier ist unser tatsächlicher Prozess:

1. Standardmäßig Playwright für neue Projekte. Seine Geschwindigkeit, kostenlose Parallelisierung und TypeScript-first-DX passen zu unserem Next.js/React-Stack. Wir schreiben E2E-Tests neben Features -- nicht nach dem Sprint, nicht "wenn wir Zeit haben", sondern als Teil der Definition of Done.

2. Cypress verwenden, wenn ein Client-Team bestehende Cypress-Infrastruktur hat und Migration nicht gerechtfertigt ist. Wir drängen Teams nicht aus dem Sake der Migration zur Migration. Wenn Cypress funktioniert und das Team produktiv ist, helfen wir ihnen, mehr daraus herauszuholen.

3. Teams von Selenium migrieren helfen, wenn die Wartungslast die Migrationskosten übersteigt -- was häufiger vorkommt, als man denken würde. Selenium-Suites neigen dazu, über Jahre komplexe Wait-Logik und spröde Selektoren anzusammeln.

Unser typischer Testing-Stack: Playwright für E2E, React Testing Library für Component-Level-Tests und GitHub Actions für CI. Diese Kombination deckt die gesamte Testing-Pyramide mit minimaler Tooling-Komplexität ab.

Brauchen Sie Hilfe bei der Einrichtung automatisierter Tests für Ihre Web-App? Unser Team implementiert Playwright- und Cypress-Testing in React-, Next.js- und Node.js-Projekten. Holen Sie sich eine kostenlose Testing-Beratung.

Endgültiges Fazit

Für die meisten Teams, die 2026 ein neues Projekt starten, ist Playwright die Standardwahl. Es ist das schnellste, fähigste und komplett kostenlos. Es gewinnt 9 von 12 Kategorien in der obigen Tabelle.

Aber Standards sind nicht universell. Cypress bleibt die richtige Wahl für Frontend-Teams, die interaktives Debugging und Component Testing priorisieren -- und die innerhalb seiner Architektureinschränkungen leben können. Selenium bleibt unverzichtbar für Java/Python-Unternehmensumgebungen mit bestehender Test-Infrastruktur und für die zunehmend seltenen Fälle, in denen IE-Unterstützung wichtig ist.

Die schlechteste Entscheidung ist Analyse-Lähmung. Bewerten Sie die Sprache Ihres Teams, Ihre Browser-Anforderungen, Ihr CI-Budget und Ihre Debugging-Präferenzen. Wählen Sie eine aus. Beginnen Sie, Tests zu schreiben. Sie können später immer migrieren -- und wie wir oben gezeigt haben, ist der Migrationspfad gut dokumentiert.

Quellen

• Playwright-Dokumentation
• Cypress Cloud-Preise
• npm Trends -- Playwright vs. Cypress vs. Selenium
• Checkly -- Geschwindigkeits-Vergleichs-Benchmark
• Next.js -- Testing mit Playwright
• State of JavaScript 2024 -- Testing-Bibliotheken
• BigBinary -- Warum wir von Cypress zu Playwright gewechselt haben

Playwright vs. Cypress vs. Selenium: FAQ

Ist Playwright besser als Cypress?

Für die meisten Teams in 2026, ja. Playwright ist schneller (2x in Benchmarks), unterstützt mehr Browser und Sprachen, hat kostenlose Parallelisierung und bessere TypeScript-Unterstützung. Cypress gewinnt beim interaktiven Debugging-DX und bei der Component-Testing-Reife. Wenn diese beiden Dinge Ihre oberste Priorität sind, ist Cypress immer noch eine starke Wahl.

Ersetzt Playwright Selenium?

Im JavaScript/TypeScript-Ökosystem weitgehend ja. Playwrights npm-Downloads sind rund 4,5x Cypress und 17x Selenium WebDriver. Aber Selenium bleibt dominant in Java- und Python-Unternehmensumgebungen, wo seine mehrsprachige Unterstützung und jahrzehntelange Ökosystem-Tools unerlässlich sind. Selenium ist nicht tot -- es verengt sich auf seine Nische.

Was ist schneller, Playwright oder Cypress?

Playwright läuft Test-Suites rund 2x schneller -- 4,5 Sekunden vs. 9,4 Sekunden in vergleichbaren Benchmarks. Der Abstand wächst mit größeren Suites, weil Playwrights Browser-Kontext-Modell effizienter ist als Cypress' Prozessmodell. Ein Team berichtete von einer 89%igen Reduktion der gesamten CI-Zeit nach der Migration.

Unterstützt Cypress Safari?

Cypress hat experimentelle WebKit-Unterstützung, aber sie gilt nicht als produktionsreif. Playwright beinhaltet WebKit (Safaris Rendering-Engine) als erstklassigen, vollständig unterstützten Browser, der auf jedem Betriebssystem läuft. Wenn Safari-Testing für Ihre Benutzer kritisch ist, ist Playwright die sicherere Wahl.

Ist Selenium 2026 tot?

Nein. Selenium ist immer noch das weltweit am weitesten verbreitete E2E-Framework, besonders in Java- und Python-Ökosystemen. Es ist die einzige Option für IE/Legacy-Browser-Testing. Aber für neue JavaScript/TypeScript-Projekte sind Playwright und Cypress nach jedem praktischen Maßstab bessere Wahlen.

Kann Playwright mobile Apps testen?

Playwright kann mobile Browser emulieren (Chrome für Android, Safari für iOS via WebKit) mit präziser Viewport-, Touch- und User-Agent-Simulation. Es kann keine nativen mobilen Apps automatisieren. Für natives App-Testing benötigen Sie Appium (das Seleniums WebDriver-Protokoll verwendet) oder ein dediziertes mobiles Test-Framework wie Detox.

Sollte ich zuerst Playwright oder Cypress lernen?

Wenn Sie 2026 neu im E2E-Testing sind, beginnen Sie mit Playwright. Es hat die stärkste Wachstumstrajektorie, das umfassendste Feature-Set, und die Fähigkeiten übertragen sich auf jedes JavaScript/TypeScript-Projekt. Cypress ist es wert, zu lernen, wenn Ihr Team es bereits verwendet oder wenn interaktives Debugging Ihr primäres Anliegen ist.

Was sind die Nachteile von Playwright?

Playwrights interaktive Debugging-Erfahrung ist weniger poliert als Cypress' Test Runner (obwohl Playwright UI-Modus den Abstand schließt). Sein Component Testing ist weniger ausgereift als Cypress'. Und sein schneller monatlicher Release-Takt bedeutet, dass sich die API-Oberfläche häufig ändert -- Sie müssen mit Updates Schritt halten.

Wie viel kostet Cypress Cloud?

Cypress Cloud beginnt bei €62/Monat (jährlich abgerechnet) für den Team-Plan mit 120.000 Testergebnissen pro Jahr, und steigt auf €247/Monat für Business mit unbegrenzten Ergebnissen. Enterprise-Preise sind individuell. Playwright bietet gleichwertige Features -- Parallelisierung, Test-Analytik via HTML-Reporter und Flake-Erkennung via Wiederholungen -- kostenlos an.

Welches E2E-Framework funktioniert am besten mit GitHub Actions?

Alle drei funktionieren mit GitHub Actions, aber Playwright erfordert die wenigste Konfiguration. Playwrights offizielle Docker-Images und eingebautes Sharding (--shard=1/4) machen die CI-Einrichtung zu einer einzigen YAML-Datei. Cypress benötigt seine offizielle GitHub Action und ein Cypress Cloud-Abonnement für Parallelisierung. Selenium benötigt einen Service-Container für den Browser-Treiber.

Funktioniert Playwright mit Java oder Python?

Ja. Playwright hat offizielle Java-, Python-, C#- und JavaScript/TypeScript-Bindings, die von Microsoft gepflegt werden. Cypress ist nur JavaScript/TypeScript. Das macht Playwright zu einer überzeugenden Selenium-Alternative für Nicht-JS-Teams, die moderne Tooling wollen, ohne die Sprache zu wechseln.

Wie migriere ich von Selenium zu Playwright?

Beginnen Sie damit, Playwright neben Selenium zu installieren. Übersetzen Sie Tests schrittweise: page.locator() ersetzt driver.findElement(), page.goto() ersetzt driver.get(), und Sie können alle expliziten Wartezeiten entfernen, weil Playwright automatisch wartet. Aktualisieren Sie Ihre CI-Konfiguration, führen Sie beide Frameworks während des Übergangs parallel aus, dann deprecieren Sie Selenium, sobald alle Tests grün sind. Eine typische 200-Test-Suite dauert 1-2 Sprints für einen Ingenieur.