E2Eテストを書くためのスタイルガイド

このドキュメントでは、GitLab QA プロジェクトを使ってエンドツーエンド (E2E) テストを書く際に GitLab で使われている規約について説明します。

このガイドは、主要なテスト標準とスタイルガイドラインの拡張版です。このガイドが、主要なガイドと矛盾するルールを定義している場合は、このガイドが優先されます。

click_ 対してgo_to_

click_ をいつ使うか?

ナビゲートする単一のリンクを選択する場合は、click_ を使用します。

使用例:

def click_ci_cd_pipelines
  within_sidebar do
    click_element(:link_pipelines)
  end
end

テストの観点から、リンクやボタンを選択すること(1つのインタラクション)が意図したとおりに動作していることをチェックしたい場合、テストは次のように記述します:

  • ある要素を選択します
  • アクションの確認

go_to_ をいつ使用しますか?

複数の要素を操作してページに移動する場合は、go_to_ を使用します。

使用例:

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 :<descriptor>_<type>

  • descriptor:自然言語による要素の説明。ログインページでは、これはusername 、またはpasswordとなります。
  • type:ユーザーが見ることができるページ上の一般的なコントロール。
    • _button
    • _checkbox
    • _container他の要素を含みますが、それ自身は表示されません。例えば、サードパーティのエディタを内部に持ちますが、エディタそのものではないため、エディタのコンテンツを含まない要素です。
    • _contentテキスト、画像、その他ユーザーに表示されるコンテンツを含む要素。
    • _dropdown
    • _fieldテキスト入力要素。
    • _link
    • _modalポップアップモーダルダイアログ。
    • _placeholderコンテンツの読み込み中に表示される一時的な要素。例えば、ディスカッションの取得中にディスカッションの代わりに表示される要素。
    • _radio
    • _tab
    • _menu_item
note
リストされたタイプが適切でない場合、適切なタイプをリストに追加するためにマージリクエストを開いてください。

使用例

良い

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

悪い

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

ブロック引数の命名

.perform メ ソ ッ ド を使用す る 際にページ と リ ソ ース の呼び方を統一す る ために、 ページオブジ ェ ク ト の名前をsnake_case(すべて小文字、 単語間はア ン ダース コ アで区切 る ) で表 し ます。以下の良い例と悪い例を参照してください。

ほとんどの場合、標準に従うことを好みますが、名前があいまいでない限り、一般的な略語(たとえば、mr )や他の代替を使うことも許容されます。混乱を避けたり、コードを読みやすくするのに役立つのであれば、_page を追加することもできます。new_page たとえば、ページオブジェクトの名前がNewである場合、ブロック引数の名前がnew であると、オブジェクトのインスタンス化に使用されるため混乱する可能性があります。

page を使わないことにしたのは、Capybara DSLに影を落とすことになり、混乱やバグにつながる可能性があるからです。

使用例

良い

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.perform do |new_page|
  new_page.do_something
end

悪い

Page::Project::Members.perform do |project_settings_members_page|
  project_settings_members_page.do_something
end
Page::Project::New.perform do |page|
  page.do_something
end

標準があることの利点に加え、この標準に従うことで、より短い行数のコードを書くことができます。