Style guide for writing end-to-end tests

- When to use click_?
Element naming convention
Block argument naming

Style guide for writing end-to-end tests

本文档介绍了在 GitLab 上使用 GitLab QA 项目编写端到端（E2E）测试所使用的约定.

单击单个链接进行导航时，请使用click_ .

E.g.:

从测试的角度来看，如果我们要检查单击链接或按钮（单个交互）是否按预期工作，我们希望测试的内容为：

点击某个元素
验证操作是否发生

与多个元素进行交互以转到页面时，请使用go_to_ .

E.g.:

def go_to_operations_environments
    within_submenu do
      click_element(:operations_environments_link)
    end
  end
end

请注意，在上面的示例中，在单击之前，将鼠标悬停在另一个元素上.

在页面上添加新元素时，重要的是要有统一的元素命名约定.

我们遵循一个基于匈牙利表示法的简单公式.

Formula: element :<descriptor>_<type>

descriptor ：元素是什么的自然语言描述. 在登录页面上，可以是username或password .
type ：用户可以在页面上看到的通用控件.
- _button
- _checkbox
- _container ：包含其他元素但本身不显示可见内容的元素. 例如，其中具有第三方编辑器的元素，但它本身不是编辑器，因此不包含编辑器的内容.
- _content ：包含文本，图像或显示给用户的任何其他内容的任何元素.
- _dropdown
- _field ：文本输入元素.
- _link
- _modal ：弹出的模式对话框，例如确认提示.
- _placeholder ：加载内容时出现的临时元素. 例如，在获取讨论时显示的元素而不是讨论.
- _radio
- _tab

注意：如果列出的类型都不适合，请打开合并请求以将适当的类型添加到列表中.

view '...' do
  element :edit_button
  element :notes_tab
  element :squash_checkbox
  element :issue_title_content
end

Bad

为了对使用.perform方法时调用的页面和资源有一个标准，我们在.perform使用页面对象的（全部小写，单词之间用下划线分隔）. 请参阅下面的好与坏示例.

尽管在大多数情况下我们倾向于遵循该标准，但是只要名称不明确，也可以使用常见缩写（例如mr ）或其他替代方式. 如果有助于避免混淆或使代码更具可读性，则可以包括附加_page . 例如，如果一个页面对象被命名为New ，也可能是混淆命名块论点new ，因为这是用来实例化对象，所以new_page是可以接受的.

我们选择不只是使用page因为这会遮盖 Capybara DSL，从而可能导致混乱和错误.

Good

Page::Project::Members.perform do |members|
  members.do_something
end

Resource::MergeRequest.fabricate! do |merge_request|
  merge_request.do_something_else
end

Page::Project::New.peform do |new_page|
  new_page.do_something
end

Bad

Page::Project::Members.perform do |project_settings_members_page|
  project_settings_members_page.do_something