# Style guide for writing end-to-end tests > 原文：[https://docs.gitlab.com/ee/development/testing_guide/end_to_end/style_guide.html](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/style_guide.html) * [`click_` versus `go_to_`](#click_-versus-go_to_) * [When to use `click_`?](#when-to-use-click_) * [When to use `go_to_`?](#when-to-use-go_to_) * [Element naming convention](#element-naming-convention) * [Examples](#examples) * [Block argument naming](#block-argument-naming) * [Examples](#examples-1) # Style guide for writing end-to-end tests[](#style-guide-for-writing-end-to-end-tests "Permalink") 本文檔介紹了在 GitLab 上使用 GitLab QA 項目編寫端到端（E2E）測試所使用的約定. ## `click_` versus `go_to_`[](#click_-versus-go_to_ "Permalink") ### When to use `click_`?[](#when-to-use-click_ "Permalink") 單擊單個鏈接進行導航時，請使用`click_` . E.g.: ``` def click_ci_cd_pipelines within_sidebar do click_element :link_pipelines end end ``` 從測試的角度來看，如果我們要檢查單擊鏈接或按鈕（單個交互）是否按預期工作，我們希望測試的內容為： * 點擊某個元素 * 驗證操作是否發生 ### When to use `go_to_`?[](#when-to-use-go_to_ "Permalink") 與多個元素進行交互以轉到頁面時，請使用`go_to_` . E.g.: ``` def go_to_operations_environments hover_operations do within_submenu do click_element(:operations_environments_link) end end end ``` `go_to_`適合與多個元素進行交互的定義，因為它更多的是包含多個交互的元導航操作. 請注意，在上面的示例中，在單擊`:operations_environments_link`之前，將鼠標懸停在另一個元素上. > 我們可以創建這些方法作為抽象多步導航的助手. ## Element naming convention[](#element-naming-convention "Permalink") 在頁面上添加新元素時，重要的是要有統一的元素命名約定. 我們遵循一個基于匈牙利表示法的簡單公式. *Formula*: `element :<descriptor>_<type>` * `descriptor` ：元素是什么的自然語言描述. 在登錄頁面上，可以是`username`或`password` . * `type` ：用戶可以在頁面上看到的通用控件. * `_button` * `_checkbox` * `_container` ：包含其他元素但本身不顯示可見內容的元素. 例如，其中具有第三方編輯器的元素，但它本身不是編輯器，因此不包含編輯器的內容. * `_content` ：包含文本，圖像或顯示給用戶的任何其他內容的任何元素. * `_dropdown` * `_field` ：文本輸入元素. * `_link` * `_modal` ：彈出的模式對話框，例如確認提示. * `_placeholder` ：加載內容時出現的臨時元素. 例如，在獲取討論時顯示的元素而不是討論. * `_radio` * `_tab` * `_menu_item` *注意：如果列出的類型都不適合，請打開合并請求以將適當的類型添加到列表中.* ### Examples[](#examples "Permalink") **Good** ``` view '...' do element :edit_button element :notes_tab element :squash_checkbox element :username_field element :issue_title_content end ``` **Bad** ``` view '...' do # `_confirmation` should be `_field`. what sort of confirmation? a checkbox confirmation? no real way to disambiguate. # an appropriate replacement would be `element :password_confirmation_field` element :password_confirmation # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`. # If it's a checkbox, it should be `clone_checkbox` element :clone_options # how is this url being displayed? is it a textbox? a simple span? # If it is content on the page, it should be `ssh_clone_url_content` element :ssh_clone_url end ``` ## Block argument naming[](#block-argument-naming "Permalink") 為了對使用`.perform`方法時調用的頁面和資源有一個標準，我們在`.perform`使用頁面對象的[名稱](https://en.wikipedia.org/wiki/Snake_case) （全部小寫，單詞之間用下劃線分隔）. 請參閱下面的好與壞示例. 盡管在大多數情況下我們傾向于遵循該標準，但是只要名稱不明確，也可以使用常見縮寫（例如`mr` ）或其他替代方式. 如果有助于避免混淆或使代碼更具可讀性，則可以包括附加`_page` . 例如，如果一個頁面對象被命名為`New` ，也可能是混淆命名塊論點`new` ，因為這是用來實例化對象，所以`new_page`是可以接受的. 我們選擇不只是使用`page`因為這會遮蓋 Capybara DSL，從而可能導致混亂和錯誤. ### Examples[](#examples-1 "Permalink") **Good** ``` Page::Project::Members.perform do |members| members.do_something end ``` ``` Resource::MergeRequest.fabricate! do |merge_request| merge_request.do_something_else end ``` ``` Resource::MergeRequest.fabricate! do |mr| mr.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 end ``` ``` Page::Project::New.peform do |page| page.do_something end ``` > 除了采用標準的優點之外，通過遵循該標準，我們還編寫了較短的代碼行.