이 문서는 GitLab QA 프로젝트를 사용하여 엔드투엔드(E2E) 테스트를 작성할 때 GitLab에서 사용하는 규칙을 설명합니다.

이 가이드는 기본 테스트 표준 및 스타일 가이드라인의 확장입니다. 이 가이드가 기본 가이드와 상충하는 규칙을 정의하는 경우, 이 가이드가 우선합니다.

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(설명자): 요소가 무엇인지에 대한 자연어 설명. 로그인 페이지에서는 username 또는 password가 될 수 있습니다.

• type(타입): 사용자가 볼 수 있는 페이지의 일반적인 컨트롤.

-button

• -checkbox

• -container: 다른 요소를 포함하지만 자체적으로 표시 가능한 콘텐츠를 제공하지 않는 요소. 예를 들어, 내부에 써드파티 에디터가 있지만 에디터 자체는 아니어서 에디터의 콘텐츠를 포함하지 않는 요소.

• -content: 텍스트, 이미지 또는 사용자에게 표시되는 기타 콘텐츠를 포함하는 요소.

• -dropdown

• -field: 텍스트 입력 요소.

• -link

• -modal: 팝업 모달 다이얼로그. 예를 들어, 확인 프롬프트.

• -placeholder: 콘텐츠가 로드되는 동안 표시되는 임시 요소. 예를 들어, 토론이 가져와지는 동안 토론 대신 표시되는 요소.

• -radio

• -tab

• -menu_item

나열된 타입 중 적합한 것이 없으면, 목록에 적절한 타입을 추가하기 위한 머지 리퀘스트를 여십시오.

예시#

Good(좋은 예)

view '...' do
  element 'edit-button'
  element 'notes-tab'
  element 'squash-checkbox'
  element 'username-field'
  element 'issue-title-content'
end

Bad(나쁜 예)

view '...' do
  # `'-confirmation'`은 `'-field'`여야 합니다. 어떤 종류의 확인인가요? 체크박스 확인인가요? 명확히 구분할 방법이 없습니다.
  # 적절한 대체는 `element 'password-confirmation-field'`가 될 것입니다.
  element 'password-confirmation'

  # `'clone-options'`는 너무 모호합니다. 드롭다운 메뉴라면 `'clone-dropdown'`이어야 합니다.
  # 체크박스라면 `'clone-checkbox'`여야 합니다.
  element 'clone-options'

  # 이 URL이 어떻게 표시되고 있나요? 텍스트박스인가요? 단순한 span인가요?
  # 페이지의 콘텐츠라면 `'ssh-clone-url-content'`여야 합니다.
  element 'ssh-clone-url'
end

블록 인수 명명#

.perform 메서드를 사용할 때 페이지와 리소스를 어떻게 부를지에 대한 표준을 갖추기 위해, snake_case(모두 소문자, 단어는 밑줄로 구분)로 된 페이지 객체의 이름을 사용합니다. 좋은 예와 나쁜 예는 아래를 참조하십시오.

대부분의 경우 표준을 따르는 것을 선호하지만, 이름이 모호하지 않은 한 공통 약어(예: mr)나 다른 대안을 사용하는 것도 허용됩니다. 혼란을 피하거나 코드 가독성을 높이는 데 도움이 된다면 _page를 추가하는 것도 포함될 수 있습니다. 예를 들어, 페이지 객체의 이름이 New라면, new는 객체를 인스턴스화하는 데 사용되기 때문에 블록 인수를 new로 명명하면 혼란스러울 수 있으므로, new_page가 허용됩니다.

page는 Capybara DSL을 가리게 되어 혼란과 버그로 이어질 수 있으므로 사용하지 않기로 했습니다.

예시#

Good(좋은 예)

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

Bad(나쁜 예)

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

표준이 마련됨으로써 얻는 장점 외에도, 이 표준을 따름으로써 더 짧은 코드를 작성할 수 있습니다.