A practice sandbox for test automation

Every page here is a small, deliberately-built widget for practicing a specific locator strategy or UI action — from a plain button with a stable id to a page that regenerates its ids on every load, from a native dropdown to nested iframes and open shadow roots.

Each drill is tagged with the locator types and action types it teaches, a difficulty tier, and (where relevant) known gotchas for Selenium, Playwright, Cypress, and WebdriverIO. Browse by category, difficulty, or jump straight to the full catalog.

Drills are deliberately small and isolated — one skill at a time. Once a few feel comfortable, a Scenario strings several of them together into a realistic, multi-step flow, closer to what you'd actually be asked to automate on the job.

Every scenario with real persisted state also exposes a seed and reset API — see Test Data & Fixtures for the full list. Managing preconditions and cleanup is its own skill worth practicing, separate from any one flow.

The Locator Inspector

Every drill page carries a small toolbar docked at the bottom of the screen — press I or click it to open. Paste a CSS selector or an XPath expression and matching elements are highlighted live on the page, with a count badge showing exactly how many elements matched (a good reminder that "first match" and "only match" are not the same thing). Toggle "pierce shadow DOM" to search inside open shadow roots too.

This is a companion project to krishanchawla.com and DevTools.

Why this exists

Most "practice" sites for test automation are either a single TodoMVC clone dressed up three different ways, or a paid platform behind a signup wall. Neither one produces the kind of problem that actually shows up in a real product — a payment step that's flaky on purpose, an id that regenerates on every reload, state that's shared across sessions instead of private to yours. I wanted something free, fast to load, and honest about what each page is actually testing, built the same way I'd want the product under test to behave: predictable where it should be, and deliberately awkward exactly where real systems are awkward.

How it's built

Astro in server mode, with a custom Node entry point (not the framework's own preview server) so a real ws WebSocket can sit next to the page router for the live chat scenario — the same process serves static pages, handles form posts, and upgrades socket connections. Solid.js shows up only where genuinely interdependent client-side state earns it (a filterable catalog, a kanban board); everything else is plain HTML and vanilla JavaScript on purpose, because that's what the DOM you're actually testing against looks like. The "API scenarios" use real patterns, not simplified ones — HMAC-signed stateless tokens, Stripe-style idempotency keys, resource-scoped tenant isolation — the same shapes you'd hit integrating against a real backend.

What's next

Ideas on the list, not promises: more accessibility-focused drills (ARIA state, focus management, screen reader landmarks), a couple of longer chained-API scenarios that combine several of the existing test-data patterns into one flow, and visual-regression-style practice (an element that shifts by a few pixels depending on viewport). If there's a specific real-world testing headache you keep running into that isn't represented here, that's exactly the kind of thing this site is meant to grow toward.