엔드 투 엔드 테스트 작성 스타일 가이드
이 문서는 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_는 여러 요소와 상호작용하는 것으로, 여러 상호작용을 포함하는 메타 탐색 동작에 매우 적합합니다.
위 예제에서 'nav-item-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
표준을 가지고 있는 이점 외에도, 이 표준을 따르면 더 짧은 코드 줄을 작성할 수 있습니다.
도움말