Wenn Sie ein Testautomatisierungsprojekt starten, wird schnell die Frage Selenium vs. Playwright auftauchen. In den Suchergebnissen mag es wie eine geklärte Angelegenheit klingen, aber die richtige Antwort hängt von Ihrem Team, Ihren vorhandenen Tests und den Browsern ab, die Sie unterstützen müssen.

Dieser Leitfaden vergleicht sie anhand der Dinge, die Sie bei der täglichen Arbeit tatsächlich spüren werden. Die Codebeispiele zeigen den typischen Stil jedes Tools und wurden für diesen Artikel nicht ausgeführt. Wir vermeiden auch die Angabe von Geschwindigkeitsprozentsätzen, da die veröffentlichten Benchmarks stark variieren und häufig von Anbietern stammen. Messen Sie anhand Ihrer eigenen Anwendung, ob die Geschwindigkeit ausschlaggebend ist.

Die kurze Antwort

Wählen Sie Playwright für die meisten neuen Webtestprojekte, insbesondere wenn Ihr Team in JavaScript, TypeScript, Python, Java oder .NET arbeiten kann. Sie erhalten sofort mehr Funktionen und benötigen weniger Zeit für die Infrastruktur und kurze Wartezeiten.

Wählen Sie Selenium, wenn Sie bereits über eine große, funktionierende Suite verfügen, wenn Sie eine Sprache benötigen, die Playwright nicht offiziell unterstützt, wie etwa Ruby, oder wenn Sie echte Browser-Builds und Plattformen testen müssen, die über ein Selenium-Grid oder eine Geräte-Cloud verfügbar sind.

Selenium vs. Dramatiker nebeneinander

Architektur: wie jeder mit dem Browser kommuniziert

Selenium sendet Befehle mithilfe des W3C WebDriver-Protokolls, einem formalen Standard. Ihr Code kommuniziert mit einem Treiber wie ChromeDriver, der den Browser steuert, wobei jeder Befehl normalerweise eine separate HTTP-Anfrage ist. Da Browser-Anbieter diesen Standard unterstützen, ist er weitgehend kompatibel. Ein neueres Protokoll, WebDriver BiDi, erweitert den Standard um bidirektionale Kommunikation und Ereignis-Streaming.

Playwright hält eine dauerhafte Verbindung zum Browser aufrecht und verwendet seine eigenen gepatchten Builds von Chromium, Firefox und WebKit. Da die Verbindung direkt und bidirektional ist, kann sie auf Browserereignisse reagieren und jeder Test kann in seinem eigenen, kompakten Browserkontext ausgeführt werden. Aus diesem Grund bewerten die meisten Vergleiche Playwright als schneller, obwohl der tatsächliche Abstand von Ihrer Anwendung und Ihren Tests abhängt.

Ein Test in beiden Tools

Hier ist derselbe in Python geschriebene Anmeldetest für eine öffentliche Übungsseite.

Selen

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def test_login(driver):
    driver.get("https://the-internet.herokuapp.com/login")
    driver.find_element(By.ID, "username").send_keys("tomsmith")
    driver.find_element(By.ID, "password").send_keys("SuperSecretPassword!")
    driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()

    message = WebDriverWait(driver, 10).until(
        EC.visibility_of_element_located((By.ID, "flash"))
    )
    assert "You logged into a secure area" in message.text

Sie benötigen außerdem eine Vorrichtung, um den Treiber zu erstellen und zu schließen, wie wir in unserem Selenium Python-Tutorial zeigen.

Dramatiker

from playwright.sync_api import Page, expect

def test_login(page: Page):
    page.goto("https://the-internet.herokuapp.com/login")
    page.get_by_label("Username").fill("tomsmith")
    page.get_by_label("Password").fill("SuperSecretPassword!")
    page.get_by_role("button", name="Login").click()

    expect(page.locator("#flash")).to_contain_text("You logged into a secure area")

Dies basiert auf dem Plugin pytest-playwright, das das Gerät page bereitstellt. Es ist kürzer, hauptsächlich weil die Wartezeit in expect integriert ist und weil Locators wie get_by_role die Seite so beschreiben, wie ein Benutzer sie sieht. Mit Selenium können Sie diesen Boilerplate mit Helfern und dem Page Object Model, das wir in beiden Tools empfehlen, erheblich reduzieren.

Warten und flockige Tests

Das Timing ist die häufigste Ursache für unzuverlässige Browsertests und hier unterscheiden sich die beiden Tools im Alltagsgebrauch am meisten.

In Selenium sind Sie für die Synchronisierung verantwortlich. Explizites Warten funktioniert gut, aber irgendjemand muss sich überall daran erinnern, und Teams, die es vergessen, greifen oft auf time.sleep zurück. Unser Leitfaden zu Selenium-Wartezeiten erklärt, wie man das richtig macht.

In Playwright prüfen Aktionen automatisch, ob ein Element sichtbar, stabil, aktiviert und in der Lage ist, Ereignisse zu empfangen, bevor sie handeln. Web-First-Assertions werden bis zu einer Zeitüberschreitung wiederholt. Sie können immer noch unzuverlässige Tests schreiben, zum Beispiel mit schlechten Testdaten, aber eine Hauptursache für Probleme wird standardmäßig behoben.

Browser und Sprachen

Hier hat Selen einen echten Vorteil. Der WebKit-Build von Playwright ähnelt der Engine von Safari, ist jedoch nicht dasselbe wie Safari auf einem Mac oder iPhone. Wenn echtes Safari-Verhalten von entscheidender Bedeutung ist, bringt Sie Selenium mit SafariDriver oder eine echte Geräte-Cloud näher an das heran, was Ihre Benutzer tatsächlich ausführen.

Ebenso testet Playwright seine gebündelten Browserversionen, kann aber auch installierte Chrome- und Edge-Kanäle steuern. Selenium steuert die von Ihnen installierten Browser, was hilfreich ist, wenn Sie bestimmte Versionen unterstützen müssen. Für native mobile Apps gibt es keine vollständige Antwort: Appium, das auf WebDriver-Konzepten basiert, ist das übliche Tool.

Was Sprachen betrifft, unterstützt Selenium offiziell Ruby und hat eine sehr lange Geschichte in Java-Teams. Die Node.js-Version von Playwright verfügt außerdem über die umfassendsten Tools, da der vollständige Testläufer vorhanden ist. Andere Sprachen erhalten die Kernbibliothek und integrieren sie in ihre eigenen Test-Frameworks.

Debuggen

Dramatiker hat hier einen klaren Vorsprung. Sein Trace-Viewer zeichnet jede Aktion zusammen mit DOM-Snapshots, Netzwerkaufrufen und Konsolenprotokollen auf, sodass Sie einen fehlgeschlagenen CI-Lauf nach dessen Abschluss Schritt für Schritt durchgehen können. Sein UI-Modus und Codegen helfen Ihnen auch dabei, Tests schneller zu schreiben. Sehen Sie sich unser Playwright-Tutorial für Anfänger an, um zu erfahren, wie Sie sie verwenden.

Mit Selenium stellen Sie dies selbst zusammen, aus Screenshots von Fehlern, Browserprotokollen, Videos von Ihrem Grid-Anbieter und Berichten von Ihrem Test-Framework. Es funktioniert gut und viele Teams verfügen über hervorragende Setups, aber der Aufbau ist mühsam.

Netzwerk- und API-Funktionen

Playwright kann Netzwerkanfragen mit wenigen Codezeilen abfangen und verspotten, was zum Testen von Fehlerzuständen nützlich ist:

page.route("**/api/orders", lambda route: route.fulfill(status=500))

Es enthält auch einen API-Anfrage-Client, sodass Sie Testdaten über eine API erstellen können, bevor Sie den Browser steuern. Selenium 4 hat über das Chrome DevTools-Protokoll und BiDi einige Netzwerkfunktionen hinzugefügt, aber Unterstützung und Komfort variieren je nach Browser und Sprache. Viele Selenium-Benutzer fügen einen Proxy oder eine separate HTTP-Bibliothek hinzu, wie in API-Testtools.

Parallele Läufe und Skalierung

Der Runner von Playwright verwaltet parallele Worker und Sharding über CI-Maschinen hinweg mit einfachen Optionen. Browserkontexte sind kostengünstig, sodass für die Isolierung nicht für jeden Test ein ganz neuer Browser erforderlich ist.

Selenium verwendet Selenium Grid, um Tests auf Maschinen und Browserversionen zu verteilen, und Test-Frameworks kümmern sich um die Parallelität. Grid ist eher lauffähig, hat sich aber in sehr großem Maßstab bewährt und wird von vielen kommerziellen Geräte-Clouds direkt unterstützt.

Sollten Sie von Selenium zu Playwright migrieren?

Nicht automatisch. Eine funktionierende Suite ist wertvoll und eine Neufassung kostet Zeit, um das Produkt zu testen. Stellen Sie zunächst diese Fragen:

1. Gibt es ein messbares Problem? Unzuverlässige Tests oder langsames Debuggen sind gute Gründe. „Es ist neuer“ ist es nicht.
2. Wie groß ist die Suite? Hundert Tests können verschoben werden. Zehntausend ist ein Großprojekt.
3. Sind Ihre Seitenobjekte sauber? Gute Abstraktionen machen den Umzug deutlich kostengünstiger.
4. Verlassen Sie sich auf Selenium-spezifische Funktionen? Überprüfen Sie zuerst Ihre Netz- und Geräteanforderungen.

Wenn Sie sich bewegen, gehen Sie schrittweise vor. Schreiben Sie neue Tests in Playwright, migrieren Sie zuerst die fehlerhaftesten alten Tests und führen Sie beide nebeneinander aus, bis die alte Suite klein genug ist, um außer Betrieb genommen zu werden. Übersetzen Sie Tests nicht zeilenweise, da dadurch Schlafplätze und alte Locators übernommen werden. Vermeiden Sie auch die unter Testautomatisierungsfehler behandelten Fehler.

So wählen Sie aus

Am besten führen Sie einen kurzen Pilotversuch durch. Automatisieren Sie Ihre drei schwierigsten Vorgänge in jedem Tool mit Ihrer eigenen Anwendung, in Ihrem eigenen CI und vergleichen Sie den Code, die Geschwindigkeit und wie einfach Sie einen Fehler beheben können. Eine Woche an Beweisen übertrifft jeden Vergleichsartikel, einschließlich dieses. Wenn Cypress auch auf Ihrer engeren Auswahlliste steht, lesen Sie Playwright vs Cypress.

Fazit

Dramatiker ist in der Regel der einfachere Ausgangspunkt, und Selenium bleibt ein verlässlicher Standard mit großer Reichweite. Beides wird eine schlecht gestaltete Testsuite nicht retten. Wählen Sie basierend auf Ihren tatsächlichen Einschränkungen, investieren Sie in stabile Locators und gute Testdaten und konzentrieren Sie Ihre Suite auf das, was für Ihre Benutzer am wichtigsten ist.

Häufige Fragen

Lerne weiter