Style guide for writing end-to-end tests

原文:https://docs.gitlab.com/ee/development/testing_guide/end_to_end/style_guide.html

Style guide for writing end-to-end tests

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

click_ versus go_to_

When to use click_?

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

E.g.:

  1. def click_ci_cd_pipelines
  2. within_sidebar do
  3. click_element :link_pipelines
  4. end
  5. end

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

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

When to use go_to_?

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

E.g.:

  1. def go_to_operations_environments
  2. hover_operations do
  3. within_submenu do
  4. click_element(:operations_environments_link)
  5. end
  6. end
  7. end

go_to_适合与多个元素进行交互的定义,因为它更多的是包含多个交互的元导航操作.

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

我们可以创建这些方法作为抽象多步导航的助手.

Element naming convention

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

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

Formula: element :<descriptor>_<type>

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

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

Examples

Good

  1. view '...' do
  2. element :edit_button
  3. element :notes_tab
  4. element :squash_checkbox
  5. element :username_field
  6. element :issue_title_content
  7. end

Bad

  1. view '...' do
  2. # `_confirmation` should be `_field`. what sort of confirmation? a checkbox confirmation? no real way to disambiguate.
  3. # an appropriate replacement would be `element :password_confirmation_field`
  4. element :password_confirmation
  5. # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`.
  6. # If it's a checkbox, it should be `clone_checkbox`
  7. element :clone_options
  8. # how is this url being displayed? is it a textbox? a simple span?
  9. # If it is content on the page, it should be `ssh_clone_url_content`
  10. element :ssh_clone_url
  11. end

Block argument naming

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

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

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

Examples

Good

  1. Page::Project::Members.perform do |members|
  2. members.do_something
  3. end
  1. Resource::MergeRequest.fabricate! do |merge_request|
  2. merge_request.do_something_else
  3. end
  1. Resource::MergeRequest.fabricate! do |mr|
  2. mr.do_something_else
  3. end
  1. Page::Project::New.peform do |new_page|
  2. new_page.do_something
  3. end

Bad

  1. Page::Project::Members.perform do |project_settings_members_page|
  2. project_settings_members_page.do_something
  3. end
  1. Page::Project::New.peform do |page|
  2. page.do_something
  3. end

除了采用标准的优点之外,通过遵循该标准,我们还编写了较短的代码行.