For frontend engineers authoring UI — how to make components reliably locatable by tests and AI agents. Covers the official Playwright locator priority, semantic/accessible markup first, and how to add valid, unique, stable `data-testid` attributes (naming convention, uniqueness in lists, stability rules) for React, Vue, Angular, and Svelte. Use when writing or reviewing components, or when an agent needs durable locators.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Audience: frontend engineers writing the app — the counterpart to the test-author guides in
core/. Your job here is to expose a small, stable, machine-readable contract on the DOM so tests and AI agents can locate elements deterministically, without flakiness.
A data-testid is a public API for your UI's automation layer: once a test or agent depends on it, renaming it is a breaking change. Build accessible markup first, then add deliberate, well-named, unique, stable test IDs where automation needs a durable handle.
| Topic | Guide |
|---|---|
data-testid conventions (when, naming, uniqueness, stability) | data-testid-conventions.md |
| Framework patterns (React, Vue, Angular, Svelte) + centralizing IDs + production stripping | examples.md |
getByRole/getByLabel work; then add test IDs.data-testid only where role, label and text fall short — no-role custom widgets, scope containers, list rows, and dynamic or localized regions. A control getByRole already finds uniquely needs none.feature-component-element[-variant], kebab-case.user-row-${user.id} ✅ / user-row-${index} ❌.data-testid is Playwright's default testIdAttribute; don't mix data-test/data-qa.아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Production-ready CI/CD configurations for Playwright — GitHub Actions, GitLab CI, CircleCI, Azure DevOps, Jenkins, Docker, parallel sharding, reporting, code coverage, and global setup/teardown.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Automates browser interactions for testing and validating your own web applications using playwright-cli. Use when you need terminal-first browser control for navigation, form filling, screenshots, tracing, bound browser sessions, debugging, or generating Playwright test code. Only use against applications you own or have explicit authorization to test.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Battle-tested Playwright patterns for writing and debugging reliable E2E, API, component, visual, accessibility, and security tests. Use when you need locator strategy, assertions, fixtures, network mocking, auth flows, trace debugging, or framework recipes for React, Next.js, Vue, and Angular. TypeScript and JavaScript.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Step-by-step migration guides for moving to Playwright from Cypress or Selenium/WebDriver — command mappings, architecture changes, and incremental adoption strategies.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Page Object Model patterns for Playwright — when to use POM, how to structure page objects, and when fixtures or helpers are a better fit.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
QA engineering workflows on top of Playwright. Use when a QA engineer asks to design test cases from a ticket, PRD or acceptance criteria, decide what to automate, write a bug report from a failing test or trace, convert manual test cases (TestRail, Xray, CSV) into Playwright specs with case-ID traceability, or review Playwright test code and pull requests.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.