The verdict

Passing tests and a production build prove only part of a static contract. They do not prove that the public URL is reachable, that assets resolve, that language switching preserves the right metadata, that canonical points to the right page, or that a 390px viewport avoids horizontal overflow. Playwright is valuable because it tests these behaviors from the browser boundary. It is not valuable merely because it produces more DOM assertions.

What black-box adds

Unit tests ask whether a function returns an expected value. A build asks whether routes and assets can be generated. Playwright visits a URL from outside the application and observes the page, network, and interaction. They are complementary. A wrong base path can leave a build green while the production CSS, cover, or RSS link returns 404.

A minimum matrix

For each public candidate, check:

Entry: root
Entry: Chinese home
Entry: English home
Articles: Chinese
Articles: English
Metadata: canonical
Metadata: hreflang
Structure: Article
Structure: Breadcrumbs
Assets: sitemap
Assets: RSS
Assets: cover
Assets: body images
Draft route
  expected status
390x844
  no horizontal overflow
Interaction: language
Interaction: menu
Interaction: theme
Interaction: contents

Assertions should express the release contract. “The page contains a heading” is not the same as “the heading URL returns 200 and has a self-canonical.” “There is an image” is not the same as “the declared cover URL returns 200 and has a non-zero natural width.”

Why mobile needs a real viewport

Responsive failures often hide on desktop: a long heading overflows, a floating table of contents covers text, a table or code block creates horizontal scrolling, or a touch target becomes too small. A real 390x844 viewport, checked at the top, middle, bottom, and expanded states, is more diagnostic than one stitched full-page screenshot.

Interaction needs an observable result

After clicking a language switch, verify the target page’s lang, canonical, and title. After toggling the theme, verify both its accessible name and visual state. After selecting a table-of-contents item, verify the hash and heading location. After choosing a search result, verify that it opens a public article rather than a draft. “Click succeeded” is not an acceptance result; the post-click state is.

Common mistakes

Using a dev server instead of the production build; checking only HTTP status; using an old screenshot for a new commit; mistaking an Access page for site content; checking DOM existence without computed layout; and replacing an exact route set with a loose count to make a test pass all weaken the gate.

Reproducible boundary

Pin the Playwright version, build first, serve the generated output, and bind screenshots, traces, and JSON checks to the commit SHA. Playwright’s official documentation supports browser tests and reporting. This article does not claim screenshots, performance numbers, or live results that were not actually run.