Loading challenge...
Skeleton Dashboard
Four widgets load on staggered delays — wait for the ready state, not the skeleton placeholder
What you will learn
- Distinguish element presence from element readiness when automating async-loading UIs
- Use a stable data-state attribute as the synchronization signal instead of fixed sleeps
- Assert on the aggregate (all 4 widgets ready) rather than a single optimistic element check
Skeleton Dashboard — Wait for Real Data
Four widgets each fetch on a staggered delay, showing a shimmering skeleton until their data resolves — the skeleton exists in the DOM long before the value does
Each widget renders a skeleton placeholder immediately, then flips to data-state="ready" once its /api/lab/widget fetch resolves. A naive wait for element passes against the placeholder — a false positive.
Ready: 0 / 4
Live Dashboard
Wait for every widget to reach the ready state before reading its value
Revenue
Active Users
Error Rate
Latency p95
Testing Tips
Automation hints
- ✓ A plain
wait for [data-widget="revenue"]passes instantly against the skeleton — that is the false positive this challenge teaches you to avoid - ✓ Wait on the state, not mere presence:
[data-widget="revenue"][data-state="ready"] - ✓ Assert all four resolved with a count over
[data-widget][data-state="ready"]equal to 4 (delays stagger up to ~2.3s, so give it ~3s) - ✓ The numeric value lives in
[data-widget-value="<id>"]only after ready; reading it while loading returns the skeleton, not a number - ✓
#dashboard-reloadre-issues all four staggered fetches — use it to retest the loading → ready transition
