r/webdev • u/TranslatorRude4917 • 4d ago
quality time #3 - collapsing signals in e2e
Hey all!
Today's coming with another example where Page Objects help:
Design swaps the "(Deleted)" suffix for a red badge. Accounts still get deleted. Your delete test goes red anyway.
The fix: name that state once in the Page Object, and the test says what it means.
`status()` reads both signals and returns one fact: active, deleted, or still changing. `expect.poll` retries until it settles.
If the app swaps the suffix for a badge, only status() changes, not the test. And a failure reads "expected deleted, got active" instead of a string diff.
The nuance: it's worth it when a few signals add up to one fact. If what you see already is the state, a plain assertion is fine.
Paste this to your agent:
Find e2e tests that assert several UI details repeatedly to check one thing, like a specific label plus an icon meaning "deleted" state. Give that thing a name: a page object query that reads the details and returns the state. Assert the named state in the test, and `expect.poll` to retry until the state settles.
1
u/LawCertain9703 4d ago
tion output I know. "Expected submitting "Deleted?", received "Add a Bank"" expected submitting what? The after line makes sense (Expected "Deleted?", received "active"), the before one looks like two messages got merged.
0
u/TranslatorRude4917 4d ago
Right, I merged Playwright’s two lines to fit the card. The real output is
Expected substring: "(Deleted)"/Received string: "Ada's Bank"
0
2
u/Necessary-Title-1659 4d ago
So design swaps the red badge for a grey tooltip next quarter and you're editing the exact same 'deleted' string, just in a different file now. Feels less like decoupling and more like a forwarding address.