엔드 투 엔드 테스트 작성 스타일 가이드
이 문서는 GitLab에서 GitLab QA 프로젝트를 사용하여 엔드 투 엔드(E2E) 테스트를 작성하기 위해 사용하는 규칙에 대해 설명합니다.
이 가이드는 주요 테스팅 표준 및 스타일 가이드의 확장입니다. 이 가이드가 주요 가이드와 충돌하는 규칙을 정의한다면, 이 가이드가 우선합니다.
click_ 대 go_to_
click_를 사용하는 경우
단일 링크를 선택하여 이동해야 하는 경우 click_를 사용하세요.
예시:
def click_add_badge_button
click_element :add_badge_button
end
테스트 관점에서, 우리가 링크를 선택하거나 버튼을 선택하여 (단일 상호작용) 의도한 대로 작동하는지 확인하려면 테스트가 다음과 같이 나와야 합니다:
- 특정 요소를 선택합니다
- 동작이 발생했는지 확인합니다
go_to_를 사용하는 경우
여러 요소와 상호작용하여 페이지로 이동해야 하는 경우 go_to_를 사용하세요.
예시:
def go_to_applications
click_element('nav-item-link', submenu_item: 'Applications')
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`은 `_field`여야 합니다. 어떤 종류의 확인입니까? 확인 확인란입니까? 명확하게 감별할 수 있는 방법은 없습니다.
# 적절한 대체물은 `element :password_confirmation_field`일 것입니다.
element :password_confirmation
# `clone_options`은 너무 모호합니다. 드롭다운 메뉴인 경우, `clone_dropdown`여야 합니다.
# 체크박스인 경우, `clone_checkbox`여야 합니다.
element :clone_options
# 이 URL이 어떻게 표시되고 있습니까? 텍스트 상자입니까? 간단한 스팬입니까?
# 페이지의 내용인 경우, `ssh_clone_url_content`여야 합니다.
element :ssh_clone_url
end
블록 인자 명명
.perform 메서드를 사용할 때 페이지 및 리소스를 호출하는 데 사용되는 표준을 갖기 위해, 우리는 페이지 객체의 이름을 스네이크 케이스로 사용합니다
(모두 소문자로, 단어 사이는 언더스코어로 구분). 아래에 좋은 예와 나쁜 예가 나와 있습니다.
대부분의 경우에는 표준을 준수하는 것이 좋지만
명확한 이름인 경우 공통 약어(예: mr) 또는 다른 대안을 사용하는 것도 허용됩니다.
이는 혼란을 피하거나 코드를 더 읽기 쉽게 만들기 위해 _page를 추가하는 것과 관련될 수 있습니다. 예를 들어, 페이지 객체의 이름이 New인 경우 new로 블록 인자를 지정하는 것은 혼란스러울 수 있으므로 new_page가 허용될 것입니다.
우리는 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
표준을 갖는 장점 외에도, 이 표준을 따르면 코드를 더 짧게 작성할 수 있습니다.
도움말