Cookie consent and privacy
Optional measurement and Google services run only after your consent. The consent panel (CMP) stores your choice; rejecting does not block the playgrounds.
Testing Library

Testing Library Query Playground

Paste a small DOM snapshot, compare Testing Library-style queries and see exactly when getBy, queryBy and AllBy variants pass, return null, return an empty array or throw.

  • DOM stays in the browser
  • Query priority guide
  • Variant semantics

Choose the query before the test becomes brittle

Testing Library pushes tests toward user-visible behavior: roles, labels, text, display values and accessible names before implementation details. This playground gives code review a small, inspectable surface for checking what each query family and variant would do in a sanitized HTML snapshot.

The evaluator uses a detached DOMParser document, removes risky markup and never sends pasted HTML, query text or matched content to a backend.

Compare query families and variants

Choose a preset or paste markup, then switch query family, variant, role and exact matching to inspect result semantics.

Run query

Review role, label, placeholder and display value behavior in a normal sign-in form. Throws when there is no match or when multiple elements match.Best default when the element exposes a meaningful role and accessible name.

DOM and query inputs

Query result

Run a query to see variant semantics, matched elements, diagnostics and a copyable Testing Library snippet.

Testing Library query review guide

Start with user-visible contracts

Role and accessible name usually describe what the user can perceive. Labels, text and display values come before data-testid when the UI exposes a real semantic handle.

Variant choice changes failure behavior

getBy is strict and loud, queryBy is useful for absence checks, and AllBy variants make repeated UI explicit. The same DOM can be correct or failing depending on that choice.

This is an educational safe subset

The playground does not import DOM Testing Library at runtime, does not execute RegExp input and does not simulate delayed async DOM updates for findBy.

Testing Library Query Playground | Playground Forge

Review Testing Library queries before they harden into brittle tests

Practice Testing Library query variants against a sanitized DOM snapshot without uploading HTML.

01

Review Testing Library queries before they harden into brittle tests

Testing Library Query Playground is a privacy-first workbench for checking how query families and variants behave against a small DOM snapshot. Paste markup, choose getBy, queryBy, getAllBy or queryAllBy, and inspect matches, snippets and diagnostics without uploading HTML.

02

What the MVP supports

The MVP covers ByRole, ByLabelText, ByText, ByPlaceholderText, ByDisplayValue, ByAltText, ByTitle and ByTestId. It explains getBy, queryBy and AllBy failure behavior, marks findBy as an async caveat, skips RegExp execution and caps HTML size, nodes and visible results.

03

Why query semantics need a visible review surface

Testing Library query choices encode a product contract. A test that uses getByRole with a clear accessible name is very different from one that reaches for a test id or repeated text. Code review often needs to see both the selected element and the failure mode. This playground makes those states visible: no match, multiple match, null result, empty array and array result are separate outcomes. The evaluator intentionally uses a detached DOMParser document and a local sanitizer. It removes scripts, iframes, event handlers, fetch-like attributes and javascript links before matching. The raw snapshot is never rendered into the live Angular DOM, which keeps the tool useful for review without becoming an HTML execution surface. The route is an educational subset rather than a full DOM Testing Library runtime. That keeps the bundle small and the behavior explainable. It also makes the limitations explicit: no free-form RegExp, no custom normalizer, no async DOM mutation simulation and no configurable test id attribute in MVP. The most important use case for Testing Library Query Playground is a fast review of one question: "does this test describe user behaviour, or only the current DOM?". In large components it is easy to write a selector that passes today but breaks after a wrapper change, a CSS class rename or another design-system refactor. The page organizes roles, accessible names, visible text, labels and several query results, so reviewers can see whether a role-and-name query, a label query, a placeholder query or, as a last resort, a test id is the clearest choice. That keeps the discussion focused on interface semantics instead of guessing how Testing Library will interpret the fixture. The tool boundary is intentionally explicit. The playground analyzes static, sanitized HTML and does not pretend to be an application runner, a framework lifecycle, a retry loop or an async state simulator. That decision lowers privacy risk and lets teams paste a reduced DOM fragment without executing scripts, event handlers or javascript links. In practice it works best as a step before changing the test: first the minimal fixture confirms roles and accessibility names, then the target test still has to run inside the repository with the real component, mocks and application state.

04

A practical query review workflow

Start with ByRole and a name when the UI exposes a meaningful role. Move to ByLabelText for form controls, then visible text, placeholder or display value when those reflect the user contract. Treat ByTestId as a stable fallback for UI that cannot expose a durable semantic handle. Switch variants to match the assertion you plan to write. getBy is loud and useful for expected presence. queryBy is appropriate for absence checks but still fails on multiple matches. getAllBy and queryAllBy make repeated UI explicit. findBy belongs in real tests when elements appear after async updates; this playground labels it as educational-only because the DOM snapshot is static. For sensitive markup, paste a reduced fixture instead of production HTML. Keep structure, labels, roles and representative text, but remove customer data, access tokens and internal identifiers.

Query selection often sits next to locator review, matcher semantics and rule testing.

Open Playwright Locator PlaygroundOpen Jest Matcher PlaygroundOpen ESLint Rule Tester

FAQ

Does this import DOM Testing Library package?

No. The MVP uses a small browser-only evaluator that mirrors common query semantics without adding the full package to the public bundle.

Why can queryBy throw?

queryBy returns null only for no match. Like getBy, it still throws when more than one element matches.

Are RegExp queries supported?

Not in the runtime evaluator. Plain strings keep the playground predictable and avoid ReDoS-style input risks.

Does pasted HTML leave the browser?

No. The DOM snapshot is parsed and sanitized locally and is not sent to a backend.