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
使用例
良い
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
標準があることの利点に加え、この標準に従うことで、より短い行数のコードを書くことができます。