Playwright 定位器指南：getByRole、getByText、getByLabel、CSS 与 XPath
Source: Dev.to
介绍
不稳定性是测试信心的隐形杀手。一个测试套件在某一时刻通过，下一刻失败，会摧毁信任。
大多数测试不稳定的根源在于糟糕的元素选择。你的测试使用 div.btn-primary 点击按钮，随后因为 CSS 被更新而失败。它通过元素在 DOM 中的位置来定位元素，却在新功能在其上方添加内容时崩溃。它精确等待 2 秒以加载数据，却在 API 变慢时超时。每一次 UI 更新都会导致一连串的测试失败，使维护变成全职工作。
Playwright 定位器通过不同的方式解决这些根本问题：自动等待消除时序问题，严格匹配防止模糊选择，面向用户的选择器在实现变化时仍保持稳定。Playwright 鼓励你像用户一样通过角色、文本和标签来查找元素，而不是使用脆弱的 CSS 选择器和 XPath 查询。
本指南将全面探讨 Playwright 定位器的所有层面，从强烈推荐的面向用户的选择器（如 getByRole）到必要的 CSS 与 XPath 备选方案，帮助你构建一个不仅能运行且真正可靠的测试自动化套件。
Playwright 定位器策略：像用户而不是 DOM 思考
传统的测试框架迫使你像计算机一样思考：通过元素在 DOM 中的位置、CSS 类或内部 ID 来查找元素。但应用程序始终在变化。类会随样式更新而改变。DOM 结构会随框架升级而移动。ID 在每次构建时都会重新生成。如果你的测试紧耦合这些因素，任何 UI 更新都会导致连锁失败。
最常见的定位器不稳定来源包括：
- 时机问题 – 元素在你尝试交互时尚未就绪。现代 Web 应用是动态的，组件异步渲染，数据从 API 加载，动画会改变元素位置。按钮可能已经在 DOM 中，但在数据加载完成前是禁用的。模态框可能已经出现，但仍在滑入视图中。
- 选择歧义 – 多个元素匹配你的选择器。这在列表、网格和重复组件中尤为突出。你的测试在本地可能通过，因为只有一个“Delete”按钮，但在预发布环境中会失败，因为有二十个。
- 实现耦合 – 选择器绑定到实现细节而非用户可见的行为。当你使用
div.btn-primary-new-style进行选择时，你在测试实现，而不是用户体验。每一次重构都会成为测试维护的负担。 - 动态内容 – 元素会根据数据、用户状态或时间变化。仪表盘会根据用户权限显示不同的小部件。表单会逐步显示字段。内容会实时更新。
Playwright 通过其现代且有主张的元素选择方式来解决这些问题。不同于直接查询 DOM 的传统方法，Playwright 的定位器代表了我们编写自动化测试的范式转变。
Playwright 自动等待解释
导致测试不稳定的最常见原因之一是时序问题。当应用是动态的，元素以异步方式渲染、hydrate（水合）并启用时，传统的测试脚本可能会在按钮可交互之前尝试点击，导致失败。
Playwright 的自动等待机制解决了这个问题。当你对定位器执行操作时，Playwright 会在执行之前自动进行一系列检查。Playwright 自动等待，只有当定位器解析为恰好一个可见、稳定、能够接收事件且已启用的元素时（对于 fill，还需可编辑），才会执行操作。
test('auto-waiting prevents timing issues', async ({ page }) => {
// No need for explicit waits
await page.goto('/dashboard');
// Playwright waits for button to be actionable
await page.getByRole('button', { name: 'Load Report' }).click();
// Even with dynamic content loading
await expect(page.getByRole('table', { name: 'Sales Data' }))
.toBeVisible();
});