Page objects in GitLab QA · Gitlab 中文文檔

# Page objects in GitLab QA > 原文：[https://docs.gitlab.com/ee/development/testing_guide/end_to_end/page_objects.html](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/page_objects.html) * [Why do we need that?](#why-do-we-need-that) * [What problems did we have in the past?](#what-problems-did-we-have-in-the-past) * [How did we solve fragile tests problem?](#how-did-we-solve-fragile-tests-problem) * [How to properly implement a page object?](#how-to-properly-implement-a-page-object) * [Defining Elements](#defining-elements) * [Adding Elements to a View](#adding-elements-to-a-view) * [`data-qa-selector` vs `.qa-selector`](#data-qa-selector-vs-qa-selector) * [Dynamic element selection](#dynamic-element-selection) * [Examples](#examples) * [Exceptions](#exceptions) * [Define Page concerns](#define-page-concerns) * [Running the test locally](#running-the-test-locally) * [Where to ask for help?](#where-to-ask-for-help) # Page objects in GitLab QA[](#page-objects-in-gitlab-qa "Permalink") 在 GitLab 質量檢查中，我們使用一種稱為*Page Objects*的已知模式. 這意味著我們已經為用于驅動 GitLab 質量檢查方案的 GitLab 中的所有頁面建立了抽象. 每當我們在頁面上執行某項操作（例如填寫表單或單擊按鈕）時，我們僅通過與該 GitLab 區域相關聯的頁面對象來執行此操作. 例如，當 GitLab QA 測試工具登錄到 GitLab 時，它需要填寫用戶登錄名和用戶密碼. 為此，我們有一個名為`Page::Main::Login`和`sign_in_using_credentials`方法的類，這是代碼中僅有的一部分，它具有有關`user_login`和`user_password`字段的知識. ## Why do we need that?[](#why-do-we-need-that "Permalink") 我們需要頁面對象，因為只要有人在 GitLab 的源代碼中更改某些選擇器，我們就需要減少重復并避免出現問題. 想象一下，我們在 GitLab 質量檢查中有 100 個規格，并且在每次聲明之前我們都需要登錄 GitLab. 如果沒有頁面對象，則需要依靠易失性助手或直接調用 Capybara 方法. 想象一下在每個`*_spec.rb`文件/測試示例中調用`fill_in :user_login` . 以后有人在與此頁面關聯的視圖`t.text_field :login`更改為`t.text_field :username` ，它將生成一個不同的字段標識符，這將有效地破壞所有測試. 因為我們到處都在使用`Page::Main::Login.perform(&:sign_in_using_credentials)` ，所以當我們要登錄到 GitLab 時，頁面對象是唯一的事實來源，我們需要將`fill_in :user_login`更新為`fill_in :user_username`只能放在一個位置. ## What problems did we have in the past?[](#what-problems-did-we-have-in-the-past "Permalink") 由于性能原因以及構建軟件包和測試所有內容所花費的時間，我們不會針對每次提交都運行 QA 測試. 這就是為什么當有人在*新的會話*視圖中將`t.text_field :login`更改為`t.text_field :username` ，直到我們的 GitLab QA 夜間管道失敗或有人觸發了他們的`package-and-qa`操作，我們才知道這一更改.合并請求. 顯然，這樣的更改將破壞所有測試. 我們稱這個問題為*脆弱的測試問題* . 為了使 GitLab QA 更加可靠和健壯，我們必須通過在 GitLab CE / EE 視圖與 GitLab QA 之間引入耦合來解決此問題. ## How did we solve fragile tests problem?[](#how-did-we-solve-fragile-tests-problem "Permalink") 當前，當您添加新的`Page::Base`派生類時，還需要定義頁面對象所依賴的所有選擇器. Whenever you push your code to CE / EE repository, `qa:selectors` sanity test job is going to be run as a part of a CI pipeline. 此測試將驗證我們在`qa/page`目錄中實現的所有頁面對象. 失敗時，將通知您有關丟失的或無效的視圖/選擇器定義的信息. ## How to properly implement a page object?[](#how-to-properly-implement-a-page-object "Permalink") 我們建立了一個 DSL 來定義頁面對象和它實際實現的 GitLab 視圖之間的耦合. 請參閱下面的示例. ``` module Page module Main class Login < Page::Base view 'app/views/devise/passwords/edit.html.haml' do element :password_field element :password_confirmation element :change_password_button end view 'app/views/devise/sessions/_new_base.html.haml' do element :login_field element :password_field element :sign_in_button end # ... end end end ``` ### Defining Elements[](#defining-elements "Permalink") `view` DSL 方法將對應于渲染元素的 rails View，partial 或 Vue 組件. `element` DSL 方法依次聲明一個元素，需要將其相應的`data-qa-selector=element_name_snaked`數據屬性添加到視圖文件中. 您還可以定義一個值（字符串或正則表達式）以匹配實際的視圖代碼，但是出于兩個原因， **不**建議使用上述方法，建議使用該值： * 一致性：只有一種定義元素的方法 * 關注點分離：QA 使用專用的`data-qa-*`屬性，而不是重用其他組件使用的代碼或類（例如`js-*`類等） ``` view 'app/views/my/view.html.haml' do ### Good ### # Implicitly require the CSS selector `[data-qa-selector="logout_button"]` to be present in the view element :logout_button ### Bad ### ## This is deprecated and forbidden by the `QA/ElementWithPattern` RuboCop cop. # Require `f.submit "Sign in"` to be present in `my/view.html.haml element :my_button, 'f.submit "Sign in"' # rubocop:disable QA/ElementWithPattern ## This is deprecated and forbidden by the `QA/ElementWithPattern` RuboCop cop. # Match every line in `my/view.html.haml` against # `/link_to .* "My Profile"/` regexp. element :profile_link, /link_to .* "My Profile"/ # rubocop:disable QA/ElementWithPattern end ``` ### Adding Elements to a View[](#adding-elements-to-a-view "Permalink") 鑒于以下要素... ``` view 'app/views/my/view.html.haml' do element :login_field element :password_field element :sign_in_button end ``` 要將這些元素添加到視圖，必須通過為定義的每個元素添加`data-qa-selector`屬性來更改 rails View，Partial 或 Vue 組件. 在我們的示例中， `data-qa-selector="login_field"` ， `data-qa-selector="password_field"`和`data-qa-selector="sign_in_button"` **app/views/my/view.html.haml** ``` = f.text_field :login, class: "form-control top", autofocus: "autofocus", autocapitalize: "off", autocorrect: "off", required: true, title: "This field is required.", data: { qa_selector: 'login_field' } = f.password_field :password, class: "form-control bottom", required: true, title: "This field is required.", data: { qa_selector: 'password_field' } = f.submit "Sign in", class: "btn btn-success", data: { qa_selector: 'sign_in_button' } ``` 注意事項： * 元素的名稱和`qa_selector`必須匹配并使用 snake_cased * 如果該元素無條件顯示在頁面上，請向該元素添加`required: true` . 請參閱[動態元素驗證](dynamic_element_validation.html) * 您可能會在現有的頁面對象中看到`.qa-selector`類. 我們應該使用[`data-qa-selector`](#data-qa-selector-vs-qa-selector)定義方法，而不是`.qa-selector` CSS 類. ### `data-qa-selector` vs `.qa-selector`[](#data-qa-selector-vs-qa-selector "Permalink") 在 GitLab 12.1 中引入在視圖中定義元素有兩種支持的方法. 1. `data-qa-selector` attribute 2. `.qa-selector` class 任何現有的`.qa-selector`類都應視為已棄用，我們應該更喜歡`data-qa-selector`定義方法. ### Dynamic element selection[](#dynamic-element-selection "Permalink") 在 GitLab 12.5 中引入自動化測試中常見的一種情況是選擇一個"多對多"元素. 在幾個項目的列表中，如何區分選擇的內容？最常見的解決方法是通過文本匹配. 相反，更好的做法是通過唯一標識符而不是文本來匹配該特定元素. 我們通過添加`data-qa-*`可擴展選擇機制來解決此問題. #### Examples[](#examples "Permalink") **例子 1** 給出以下 Rails 視圖（以 GitLab Issues 為例）： ``` %ul.issues-list - @issues.each do |issue| %li.issue{data: { qa_selector: 'issue', qa_issue_title: issue.title } }= link_to issue ``` 我們可以通過在 Rails 模型上進行匹配來選擇特定的問題. ``` class Page::Project::Issues::Index < Page::Base def has_issue?(issue) has_element? :issue, issue_title: issue end end ``` 在我們的測試中，我們可以驗證此特定問題的存在. ``` describe 'Issue' do it 'has an issue titled "hello"' do Page::Project::Issues::Index.perform do |index| expect(index).to have_issue('hello') end end end ``` **例子 2** *通過索引…* ``` %ol - @some_model.each_with_index do |model, idx| %li.model{ data: { qa_selector: 'model', qa_index: idx } } ``` ``` expect(the_page).to have_element(:model, index: 1) #=> select on the first model that appears in the list ``` ### Exceptions[](#exceptions "Permalink") 在某些情況下，可能無法或不值得添加選擇器. 一些 UI 組件使用外部庫，包括一些第三方維護的庫. 即使 GitLab 維護了一個庫，選擇器的健全性測試也只能在 GitLab 項目中的代碼上運行，因此無法為庫中的代碼指定視圖的路徑. 在這種罕見的情況下，在頁面對象方法中使用 CSS 選擇器是合理的，并帶有注釋說明為什么不能添加`element`原因. ### Define Page concerns[](#define-page-concerns "Permalink") 某些頁面具有共同的行為，并且/或者在特定于 EE 的模塊之前添加了特定于 EE 的方法. These modules must: 1. 從`QA::Page::PageConcern`模塊`extend QA::Page::PageConcern` ，并`extend QA::Page::PageConcern` . 2. 重寫`self.prepended`方法，如果他們需要`include` / `prepend`其他模塊本身，和/或定義`view`或`elements` . 3. 將`super`稱為`self.prepended`的第一件事. 4. 包含/添加其他模塊，并在`base.class_eval`塊中定義其`view` / `elements` ，以確保在添加模塊的類中定義了它們. 這些步驟確保健全性選擇器檢查將正確檢測到問題. 例如， `qa/qa/ee/page/merge_request/show.rb`將 EE 特定方法添加到`qa/qa/page/merge_request/show.rb` （帶有`QA::Page::MergeRequest::Show.prepend_if_ee('QA::EE::Page::MergeRequest::Show')` ），其實現方式如下（僅顯示相關部分，并使用內嵌注釋引用上述 4 個步驟）： ``` module QA module EE module Page module MergeRequest module Show extend QA::Page::PageConcern # 1. def self.prepended(base) # 2. super # 3. base.class_eval do # 4. prepend Page::Component::LicenseManagement view 'app/assets/javascripts/vue_merge_request_widget/components/states/sha_mismatch.vue' do element :head_mismatch, "The source branch HEAD has recently changed." end [...] end end end end end end end ``` ## Running the test locally[](#running-the-test-locally "Permalink") 在開發過程中，您可以運行以下命令來運行`qa:selectors`測試 ``` bin/qa Test::Sanity::Selectors ``` 從`qa`目錄中. ## Where to ask for help?[](#where-to-ask-for-help "Permalink") 如果您需要更多信息，請在 Slack 上的`#quality`頻道（僅限內部，GitLab 團隊）上尋求幫助. 如果你不是一個團隊成員，你仍然需要幫助的貢獻，請打開 GitLab CE 問題追蹤的一個問題`~QA`標簽.