종단 간 테스트 작성을 위한 스타일 가이드

이 문서는 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>_<type>

  • descriptor: 요소의 자연어 설명입니다. 로그인 페이지에서는 username 또는 password일 수 있습니다.
  • type: 사용자가 볼 수 있는 페이지의 일반적인 컨트롤입니다.
    • -button
    • -checkbox
    • -container: 다른 요소를 포함하지만, 자체적으로는 가시적 콘텐츠를 표시하지 않는 요소입니다. 예를 들어, 제3자 편집기가 내부에 있지만 편집기 자체는 포함하지 않으므로 편집기 콘텐츠를 포함하지 않는 요소입니다.
    • -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은 어떻게 표시되나요? 텍스트 박스인가요? 간단한 span인가요?
  # 페이지의 콘텐츠라면 `'ssh-clone-url-content'`여야 합니다.
  element 'ssh-clone-url'
end

블록 인수 명명

.perform 메서드를 사용할 때 페이지와 리소스에 대해 우리가 부르는 것에 대한 표준을 갖기 위해
우리는 페이지 객체의 이름을 스네이크 케이스로 사용합니다
(소문자만 사용하고, 단어는 underscore로 구분됨). 아래에서 좋은 예와 나쁜 예를 확인하세요.

대부분의 경우 표준을 따르는 것을 선호하지만,
이름이 모호하지 않은 한 일반적인 약어(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

표준이 마련됨에 따라 얻는 이점 외에도, 이 표준을 따르면 우리는 더 짧은 코드 라인을 작성할 수 있습니다.