Lesson 02 · Playwright for Java

Beyond the 1Z0-830 exam

Playwright (from Microsoft) is the modern challenger to Selenium: one API drives Chromium, Firefox, and WebKit, with auto-waiting built into every action. It removes most of the manual wait code that makes Selenium suites flaky.

Objectives

After this lesson you will be able to:

• Launch a browser and drive a Page with Playwright for Java.
• Use locators and rely on auto-waiting.
• Capture traces/screenshots/video for debugging.
• Decide between Playwright and Selenium.

The Playwright model

try (Playwright playwright = Playwright.create()) {
    Browser browser = playwright.chromium().launch();    // or .firefox()/.webkit()
    Page page = browser.newPage();

    page.navigate("https://example.com/login");
    page.locator("#username").fill("ada");
    page.locator("#password").fill("secret");
    page.locator("button[type=submit]").click();

    assertThat(page).hasURL(Pattern.compile(".*/dashboard"));   // Playwright assertions auto-retry
    browser.close();
}

Playwright is AutoCloseable (try-with-resources, Module 04). A BrowserContext gives each test an isolated, cookie-free session — cheap to create, unlike a fresh browser.

Auto-waiting — the key difference

Every Playwright action (click, fill, textContent) automatically waits for the element to be present, visible, stable, and enabled before acting, up to a timeout. You rarely write an explicit wait:

page.locator("#submit").click();   // waits for #submit to be actionable, then clicks

Contrast Selenium, where you typically wrap the same action in a WebDriverWait. Playwright's web-first assertions (assertThat(locator).isVisible()) also auto-retry until they pass or time out — no manual polling.

Locators are lazy

A Playwright Locator is a description of how to find an element, resolved fresh on each action — so it survives DOM re-renders. Selenium's WebElement is a handle to one resolved element that can go stale (StaleElementReferenceException) when the page updates. Locator-based code is more robust by design.

Tracing and debugging

Playwright's killer feature for CI is the trace — a recording of every action, DOM snapshot, console log, and network call, viewable after the fact:

context.tracing().start(new Tracing.StartOptions()
    .setScreenshots(true).setSnapshots(true));
// … run the test …
context.tracing().stop(new Tracing.StopOptions().setPath(Paths.get("trace.zip")));

It also captures screenshots (page.screenshot(...)) and video per context — invaluable for diagnosing a headless CI failure.

Playwright vs Selenium

	Selenium	Playwright
Waiting	mostly manual (explicit waits)	auto-waiting built in
Element model	WebElement (can go stale)	lazy Locator (re-resolved)
Browsers	Chrome/Firefox/Edge/Safari via drivers	Chromium/Firefox/WebKit bundled
Debugging	screenshots, logs	trace viewer, video, screenshots
Maturity/ecosystem	huge, long-established	newer, growing fast
Cross-language standard	W3C WebDriver	Playwright protocol

Neither is "wrong." Selenium wins on ecosystem maturity and being the W3C standard; Playwright wins on out-of-the-box reliability and debugging. New projects increasingly pick Playwright.

SDET note

This module's lab is framework-agnostic on purpose: the LoginPage page object talks to a FakeBrowser interface, so the same page object could sit on top of Selenium's WebDriver or Playwright's Page. Good UI test architecture isolates the tool choice behind page objects (next lesson).

Key Takeaways

• Playwright drives Chromium/Firefox/WebKit from one API; Playwright is AutoCloseable.
• Auto-waiting waits for actionability on every action — far fewer manual waits than Selenium.
• A Locator is lazy and re-resolved, avoiding Selenium's stale-element problem.
• Traces, video, and screenshots make headless/CI failures debuggable.
• Choose per project: Selenium for ecosystem/standard, Playwright for built-in reliability.

Lesson Quiz

Lesson Quiz · Playwright for Java0 / 5

1. Playwright's auto-waiting means…

   • AIt sleeps a fixed time before each action
   • BEach action waits for the element to be actionable (visible/stable/enabled) before proceeding
   • CIt never waits
   • DWaits must be coded manually

2. Why is a Playwright Locator more robust than a Selenium WebElement?

   • AIt's cached forever
   • BIt's a lazy description re-resolved on each use, so it survives DOM re-renders (no stale-element errors)
   • CIt's faster to type
   • DIt only works in Chrome

3. What is a Playwright trace useful for?

   • ACompiling tests
   • BPost-mortem debugging — actions, DOM snapshots, console, and network from the run
   • CRunning the DB
   • DGenerating locators

4. A BrowserContext is used to…

   • ALaunch a new OS process per test
   • BGive each test an isolated, cheap, cookie-free session within one browser
   • CReplace assertions
   • DStore test data in a DB

5. A fair summary of Selenium vs Playwright is…

   • APlaywright is always better in every way
   • BSelenium wins on ecosystem maturity/W3C standard; Playwright wins on built-in auto-waiting and debugging
   • CThey can't test the same apps
   • DSelenium can't run headless

---

Next: Page Object Model & Design. This module's lab is in labs/src/main/java/com/jse21/m18_ui/.