Playwright Intro - discussion (2023-01-28)
Playwright's intro is a good reminder that E2E isn't about testing everything—it's about testing flows that cross boundaries (routing, data freshness, authentication posture). In apps that lean on visible evidence keys and route contracts, E2E gets a lot more deterministic.
What do you assert on in E2E: user-visible text/roles, or evidence attributes as well? How do you keep traces useful when the app has a lot of async lane changes? Do you use E2E to validate "route posture" (cache lanes, motion keys), or keep that in unit/integration tests?
Comments (12)
Back to latestI assert user-visible content first, then one evidence key per flow.
If the evidence key explains the flow (lane/posture/identity), it makes failures obvious.
Evidence + traces is a great combo. We print a tiny "tips trace" line into the page so it ends up in screenshots:
txt
[tips] route=/threads/42 panel=detail lane=ok freshnessAt=2023-02-07T05:05ZThen Playwright failures read like a story, not like a flake.
Counterpoint: asserting too much evidence can make tests brittle if you rename the vocabulary.
I keep evidence assertions to things I'd want in a customer support screenshot anyway.
Same. I treat evidence like a UI label: rename it only when the product meaning changes.
Then tests stay stable.
We use E2E for "did navigation + data fetching + rendering posture compose correctly".
Unit tests can't give you that confidence.
Traces stay useful when you align your logs to contract transitions:
txt
[tips] lane=pending reason=nav:click
[tips] lane=ok reason=fetch:resolve
[tips] motion=list->detail remountKey=thread:42We also use Playwright's built-in tracing/screenshot to validate accessibility affordances (focus, keyboard).
Even when the app postpones full keyboard support, traces help you see regressions.
Counterpoint: E2E is expensive; if you don't have deterministic contracts, you just get expensive flakes.
The contract/evidence posture is what makes E2E worth it.
Yes. Evidence lanes are basically flake prevention.
You stop guessing when async work is finished.
We keep route posture in E2E: cache lane, render cadence, panel key.
If you ship those postures, you should test them end-to-end at least once.
A cool trick is to make the evidence keys accessible via aria-describedby on a debug element.
Then Playwright can assert on it like normal content without relying on attributes.
Docs tie-in: the routing posture docs explain why E2E failures often look like routing bugs but are actually contract bugs.
Related: Routing and Navigation and Testing and Debugging.
Playwright's locator ergonomics also nudged us to improve markup (roles/labels).
Better tests and better UI come together when you lean into semantics.
The intro doc is great, but the real unlock is: treat trace artifacts as part of your debugging workflow, not just test output.
When you pair traces with contract logs, triage becomes fast.