Si vous démarrez un projet d’automatisation de tests, la question Selenium vs Playwright se posera rapidement. Les résultats de recherche peuvent donner l’impression que c’est une affaire réglée, mais la bonne réponse dépend de votre équipe, de vos tests existants et des navigateurs que vous devez prendre en charge.

Ce guide les compare sur les choses que vous ressentirez réellement dans votre travail quotidien. Les exemples de code montrent le style typique de chaque outil et nous ne les avons pas exécutés pour cet article. Nous évitons également de citer des pourcentages de vitesse, car les références publiées varient considérablement et proviennent souvent de fournisseurs. Mesurez sur votre propre application si la vitesse décidera de la question.

La réponse courte

Choisissez Playwright pour la plupart des nouveaux projets de tests Web, en particulier si votre équipe peut travailler avec JavaScript, TypeScript, Python, Java ou .NET. Vous bénéficiez de plus de fonctionnalités prêtes à l’emploi, et vous passez moins de temps sur l’infrastructure et les attentes instables.

Choisissez Selenium si vous disposez déjà d’une grande suite fonctionnelle, si vous avez besoin d’un langage que Playwright ne prend pas officiellement en charge, comme Ruby, ou si vous devez tester sur les versions de navigateur et les plates-formes réelles disponibles via une grille Selenium ou un cloud d’appareils.

Sélénium vs Dramaturge côte à côte

Architecture : comment chacun communique avec le navigateur

Selenium envoie des commandes à l’aide du protocole W3C WebDriver, une norme formelle. Votre code communique avec un pilote, tel que ChromeDriver, qui contrôle le navigateur, chaque commande étant généralement une requête HTTP distincte. Étant donné que les fournisseurs de navigateurs prennent en charge cette norme, celle-ci offre une large compatibilité. Un protocole plus récent, WebDriver BiDi, ajoute à la norme la communication bidirectionnelle et le streaming d’événements.

Playwright maintient une connexion persistante au navigateur et utilise ses propres versions corrigées de Chromium, Firefox et WebKit. La connexion étant directe et bidirectionnelle, elle peut réagir aux événements du navigateur et chaque test peut s’exécuter dans son propre contexte de navigateur léger. C’est pourquoi la plupart des comparaisons évaluent Playwright comme étant plus rapide, bien que l’écart réel dépende de votre application et de vos tests.

Un test dans les deux outils

Voici le même test de connexion, écrit en Python, sur un site de pratique publique.

Sélénium

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

Vous avez également besoin d’un appareil pour créer et fermer le pilote, comme nous le montrons dans notre Tutoriel Selenium Python.

Dramaturge

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")

Cela repose sur le plugin pytest-playwright, qui fournit le luminaire page. Il est plus court, principalement parce que l’attente est intégrée dans expect, et parce que les localisateurs comme get_by_role décrivent la page telle qu’un utilisateur la voit. Avec Selenium, vous pouvez réduire considérablement ce passe-partout avec des assistants et le Page Object Model, que nous recommandons dans l’un ou l’autre outil.

Tests d’attente et floconneux

Le timing est la principale cause des tests de navigateur irréguliers, et c’est là que les deux outils diffèrent le plus dans l’utilisation quotidienne.

Dans Selenium, vous êtes responsable de la synchronisation. Les attentes explicites fonctionnent bien, mais quelqu’un doit s’en souvenir partout, et les équipes qui les oublient se tournent souvent vers time.sleep. Notre guide sur les Selenium waits explique comment procéder correctement.

Dans Playwright, les actions vérifient automatiquement qu’un élément est visible, stable, activé et capable de recevoir des événements avant d’agir. Les assertions Web-First continuent de réessayer jusqu’à expiration du délai d’attente. Vous pouvez toujours écrire des tests irréguliers, par exemple avec des données de test médiocres, mais une source majeure de problèmes est gérée par défaut.

Navigateurs et langues

C’est là que Selenium garde un réel avantage. La version WebKit de Playwright est proche du moteur de Safari, mais ce n’est pas la même chose que Safari sur Mac ou iPhone. Si le comportement réel de Safari est critique, Selenium avec SafariDriver, ou un véritable cloud d’appareils, vous rapproche de ce que vos utilisateurs exécutent réellement.

De même, Playwright teste ses versions de navigateur fournies, bien qu’il puisse également piloter les canaux Chrome et Edge installés. Selenium pilote les navigateurs que vous installez, ce qui est utile si vous devez prendre en charge des versions spécifiques. Pour les applications mobiles natives, la réponse complète n’est pas non plus : Appium, qui repose sur les concepts WebDriver, est l’outil habituel.

Concernant les langages, Selenium prend officiellement en charge Ruby et a une très longue histoire dans les équipes Java. La version Node.js de Playwright dispose également de l’outillage le plus complet, puisque le programme d’exécution de test complet est présent. D’autres langages obtiennent la bibliothèque principale et s’intègrent à leurs propres frameworks de test.

Débogage

Le dramaturge a ici une avance évidente. Son visualiseur de traces enregistre chaque action, ainsi que les instantanés DOM, les appels réseau et les journaux de console, afin que vous puissiez parcourir une exécution de CI ayant échoué une fois celle-ci terminée. Son mode UI et son codegen vous aident également à écrire des tests plus rapidement. Consultez notre Tutoriel dramaturge pour débutants pour savoir comment les utiliser.

Avec Selenium, vous assemblez cela vous-même, à partir de captures d’écran d’échec, de journaux de navigateur, de vidéos de votre fournisseur de grille et de rapports de votre framework de test. Cela fonctionne bien et de nombreuses équipes ont d’excellentes configurations, mais cela demande des efforts de construction.

Fonctionnalités réseau et API

Playwright peut intercepter et simuler les requêtes réseau avec quelques lignes de code, ce qui est utile pour tester les états d’erreur :

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

Il comprend également un client de requête API, vous permettant ainsi de créer des données de test via une API avant de piloter le navigateur. Selenium 4 a ajouté certaines fonctionnalités réseau via le protocole Chrome DevTools et BiDi, mais la prise en charge et la commodité varient selon le navigateur et la langue. De nombreux utilisateurs de Selenium ajoutent un proxy ou une bibliothèque HTTP distincte, comme dans les outils de test d’API.

Exécutions parallèles et mise à l’échelle

Le programme d’exécution de Playwright gère les travailleurs parallèles et le partitionnement sur les machines CI avec des options simples. Les contextes de navigateur sont bon marché, donc l’isolation ne nécessite pas un tout nouveau navigateur pour chaque test.

Selenium utilise Selenium Grid pour distribuer les tests sur les machines et les versions de navigateur, et les frameworks de test gèrent le parallélisme. Grid est plus complexe à exécuter, mais il a fait ses preuves à très grande échelle et de nombreux cloud d’appareils commerciaux le prennent directement en charge.

Devriez-vous migrer de Selenium vers Playwright ?

Pas automatiquement. Une suite de travail est précieuse et une réécriture prend du temps pour tester le produit. Posez d’abord ces questions :

1. Y a-t-il un problème mesurable ? Des tests irréguliers ou un débogage lent sont de bonnes raisons. “C’est plus récent” ne l’est pas.
2. Quelle est la taille de la suite ? Une centaine de tests peuvent être déplacés. Dix mille est un projet majeur.
3. Les objets de votre page sont-ils propres ? De bonnes abstractions rendent le déplacement beaucoup moins cher.
4. Comptez-vous sur des fonctionnalités spécifiques à Selenium ? Vérifiez d’abord les besoins de votre réseau et de vos appareils.

Si vous bougez, allez-y progressivement. Écrivez de nouveaux tests dans Playwright, migrez d’abord les anciens tests les plus instables et exécutez les deux côte à côte jusqu’à ce que l’ancienne suite soit suffisamment petite pour être retirée. Ne traduisez pas les tests ligne par ligne, car cela répercute les mises en veille et les anciens localisateurs. Évitez également les erreurs décrites dans les erreurs d’automatisation des tests.

Comment choisir

Mieux encore, lancez un court pilote. Automatisez vos trois parcours les plus délicats dans chaque outil par rapport à votre propre application, dans votre propre CI, et comparez le code, la vitesse et la facilité avec laquelle vous pouvez déboguer une panne. Une semaine de preuves bat n’importe quel article comparatif, y compris celui-ci. Si Cypress figure également sur votre liste restreinte, lisez Playwright vs Cypress.

Pour conclure

Le dramaturge est généralement le point de départ le plus facile, et Selenium reste une norme fiable avec une large portée. Ni l’un ni l’autre ne sauvera une suite de tests mal conçue. Choisissez en fonction de vos contraintes réelles, investissez dans des localisateurs stables et de bonnes données de test, et concentrez votre suite sur ce qui compte le plus pour vos utilisateurs.

Questions fréquentes

Continuez à apprendre