当 Playwright 的 Locator 工具不足时

Source: Dev.to

Playwright 内置定位器的局限性

Playwright 的内置定位器工具在大多数情况下都能正常工作，但当你开始处理真实的组件库时，它可能就不够精准了。它经常会对并非真正语义化控件的元素建议使用 getByText 或 getByRole，这会导致这些定位器在实际使用中不稳定或根本无法使用。

自定义复选框

在大多数现代应用中，几乎看不到原生的 元素。相反，你会遇到使用, “、隐藏输入、ARIA 属性以及表示状态的类构建的自定义组件。正因为如此，Playwright 的断言如 toBeChecked 或 toBeDisabled 往往不可靠——复选框在 UI 上看起来是选中的，但底层 HTML 并没有以这些辅助函数期望的方式暴露状态。

掌控定位器

在这种情况下，你需要自己掌控定位器。最可靠的起点通常是屏幕上某段稳定的文本。定位到该文本后，你可以在 DOM 中向上或向下遍历，找到真实的复选框元素。

Playwright 为此提供了一个小而实用的 API：locator('..')。它会在 DOM 中向上移动一级，你可以根据需要任意链式调用。相比 xpath=../..，它更简洁，也更容易记住。随后，你可以再向下导航到表示你关心状态的确切节点。

示例定位链

const checkboxLocator = page
  .locator('p.user-select-none', { hasText: 'School-Pupil Activity Bus' })
  .locator('..')
  .locator('..')
  .locator('.special-requirement-checkbox')
  .locator('input[type="checkbox"][aria-checked="true"][disabled="disabled"]');

await expect(checkboxLocator).toBeVisible();

• 锚点是可见的标签文本。
• 定位器向上走到共享容器，然后再向下进入一个你知道足够稳定的类包装器。
• 最终定位到真实的 input 元素。
• 由于复选框是自定义的，测试断言使用 aria-checked 和 disabled，而不是依赖 toBeChecked 或 toBeDisabled。一个简单的 toBeVisible 加上正确的属性，比高级别的断言 API 更具体可靠。

为什么人工编写的定位器仍然重要

上述内容也说明了我对那些声称可以自动生成定位器和断言的 AI 测试工具持有一点怀疑的原因。真实的应用很少使用简单、语义化的 HTML 控件。大量的自定义标记、隐藏输入以及框架特有的结构都需要你去理解和遍历。就目前而言，能够在正确的文本上锚定、在 DOM 中走查并对真实属性进行断言的人类，仍然是编写高质量 Playwright 测试的最可靠方式。