自动化主要不是关于用户看到的，而是关于用户流，用户可以从头开始完成，符合产品逻辑，使用用户资源（浏览器等）。
渲染的组件通常通过视觉（屏幕截图）测试进行检查，它们的部分应该是所有覆盖范围的最低部分（Testing Pyramid），其中e2 e可以通过功能和视觉进行划分。
在大多数情况下，你关心的是存在/呈现/可见/可点击/有一些样式和属性的元素，而不是它的文本本身。文本通常由内容键定义，所以在大多数情况下不需要测试它。它可以通过单元进行测试，该元素有键，该键有值，但这不是e2 e测试的目的。
1.如果您可以访问源代码并可以更改它，最佳实践是为元素分配唯一的定位器并在e2 e中使用它。
例如

• [data-testid=heading]或page.getByDataTestId('heading')
• [data-hook=heading]个
• [data-aid=heading]个

如果你不能自己分配属性并看到这些属性-最好使用它们，它们肯定用于自动化，并且很有可能它们不会改变。
1.然后，您应该依赖元素id，但在这种情况下，您应该考虑，该id是唯一的（根据最佳实践，它应该是唯一的，但某些资源忽略了这种模式），而不是自动生成的。
1.依赖于表示其类型或使用目的的元素属性，input[type=search]，[role=heading]
1.依赖于似乎是唯一的属性类或属性与类.headingContainer、div.headingContainer之间的组合
1.依赖于自定义标签，如name，title等。但要注意，它们可以在不同的本地化上进行更改。（有时不是，有时是）
1.依靠独特的标签（例如，youtube有许多独特的标签），如ytb-video-container，ytb-video-player等。
1.依赖于href或src部分img[src*=imgur]，[href*=imgur]。这不是最佳实践，但可以在src部分不会改变的情况下使用。
1.只有在没有其他选择的情况下，您才可以使用文本来构建定位器。文本是非常敏感的区域，很容易被产品逻辑改变，并且它在网站本地化方面也有所不同。例如，如果您目前只有英语，但将来您希望该网站将被翻译为葡萄牙语，并且您应该测试它，那么您应该避免任何基于文本的定位器。
在构建定位器时，尽量让它变得更容易，如果可能的话，使用一级，如果不可能的话，依赖于组件容器并从它们中获取子元素。
范例：

const posts = await page.locator('#blogPostContainer').all();
for(const post of posts) {
  await post.getByRole('heading').click();
  // do something
}

字符串