Loading challenge...
Self-Reordering List
Select a player in a leaderboard that re-sorts and re-hashes element ids every tick — locate by stable data-player, not id or index
What you will learn
- Build resilient locators that survive DOM churn (re-sorting + volatile ids) using stable data attributes, not ids or positions
- Use freeze controls and framework auto-waiting to interact reliably with a continuously mutating list
- Verify an action's outcome through a stable result region (#action-result) rather than transient row state
Self-Reordering List — Locate Through the Churn
A live leaderboard re-sorts itself and re-hashes every element id on a timer; the only stable hook is data-player
Every tick the rows get fresh random scores, the list re-sorts, and each row's DOM id is regenerated. A locator pinned to an id or an nth index will go stale the instant the next interval fires.
The data-player attribute is the one thing that survives the churn — anchor your tests to it and let the framework auto-retry.
Live Leaderboard
Throttle the churn, freeze it, then click a player's action button
- Adascore 0
- Linusscore 0
- Gracescore 0
- Dennisscore 0
- Margaretscore 0
- Alanscore 0
No player selected yet.
Testing Tips
Automation hints
- ✓ Never locate by element
id— every row in#leaderboardis re-hashed on each tick, so any captured id is dead next interval - ✓ Never use an
nth/ positional index — the list re-sorts by random score, so row order is unstable - ✓ Anchor on the stable attribute:
[data-player="Ada"]orpage.getByText("Ada")— these auto-retry through re-renders - ✓ Click
#freeze-toggle(or rely on Playwright auto-waiting) to settle the DOM before interacting; it exposesdata-frozenfor assertions - ✓ After clicking a player's Select button, assert the chosen name in
#action-result
