• 테스트를 작성하기 전에
• 엔드 투 엔드 테스트가 필요한지 확인
• DevOps 단계 식별
• 스켈레톤 테스트 작성
  • 바깥쪽 context 블록
  • 바깥쪽 RSpec.describe 블록
  • describe 블록
  • product_group 메타데이터
  • it 블록 (예시)
• 테스트 작성
• 코드 중복 제거
• 리소스 및 페이지 객체를 사용한 테스트 설정
• 페이지 객체 작성
• 스펙 실행
• 엔드 투 엔드 테스트 병합 요청 템플릿

엔드 투 엔드 테스트 작성 초보자 가이드

이 자습서는 GitLab Community Edition 및 GitLab Enterprise Edition을 위한 엔드 투 엔드(e2e) 테스트 작성을 안내합니다.

이 자습서를 마치면 다음을 할 수 있습니다:

• 엔드 투 엔드 테스트가 필요한지 여부를 결정할 수 있습니다.
• qa/ 내의 디렉토리 구조를 이해할 수 있습니다.
• 로그인 기능을 검증하는 기본 엔드 투 엔드 테스트를 작성할 수 있습니다.
• 부족한 페이지 객체 라이브러리를 개발할 수 있습니다.

테스트를 작성하기 전에

테스트를 작성하기 전에 GitLab Development Kit (GDK)가 설정되어 있어야 합니다. 엔드 투 엔드 테스트는 다음과 같습니다:

• qa/ 디렉토리에 포함됩니다.
• 독립적이어야 합니다.
• 멱등성을 가져야 합니다.
• 필요시 리소스(프로젝트, 이슈, 사용자 등)를 생성해야 합니다.
• UI 및 API 인터페이스를 테스트하고, API를 사용하여 UI 테스트를 효율적으로 설정해야 합니다.

참고: 더 많은 정보를 원하시면 엔드 투 엔드 테스트 최상의 실행 방법을 참조하십시오.

엔드 투 엔드 테스트가 필요한지 확인

GitLab 프로젝트에 대해 엔드 투 엔드 테스트를 작성하기 전에 특정 기능의 코드 커버리지를 확인하십시오. 단위, 기능 또는 통합 수준에서 충분한 테스트 커버리지가 있는지 확인하십시오. 만약 예라고 답했다면, 엔드 투 엔드 테스트가 필요하지 않습니다.

GitLab에서 각 레벨의 테스트 분포에 대한 정보는 테스트 레벨을 참조하십시오.

• 올바른 수준에서 테스트하는 방법을 보려면 테스트 레벨 문서의 섹션을 참조하십시오.
• 기능이 얼마나 자주 변경되는지 검토하십시오. 자주 변경되지 않는 안정적인 기능은 이미 하위 수준의 테스트에서 처리되었다면 엔드 투 엔드 테스트가 필요하지 않을 수 있습니다.
• 마지막으로, 기능을 구현하는 데 참여한 개발자 및 하위 수준 테스트를 수행한 개발자들과 해당 테스트를 논의하십시오.

경고: 이 기능에 대해 이전에 작성된 테스트를 확인하려면 GitLab 커버리지 프로젝트를 확인하십시오. 코드 커버리지를 분석하려면 특정 특성을 구현하는 응용 프로그램 파일을 이해해야 합니다.

이 자습서에서는 하위 수준 테스트에서 이미 충분히 다루어져 있음에도 불구하고, 엔드 투 엔드 흐름의 첫 번째 단계이자 가장 쉬운 이유로 로그인 엔드 투 엔드 테스트를 작성하고 있습니다.

DevOps 단계 식별

GitLab QA 엔드 투 엔드 테스트는 다양한 DevOps 라이프사이클 단계별로 구성됩니다. 테스트를 어느 단계에 배치해야 하는지, 테스트가 어떤 기능에 속하는지 확인한 다음 해당 단계의 하위 디렉토리에 배치하십시오.

테스트가 Enterprise Edition 전용인 경우, 해당 테스트는 features/ee 디렉토리에 만들어지지만, 동일한 DevOps 라이프사이클 형식을 따르십시오.

스켈레톤 테스트 작성

이 자습서의 첫 번째 부분에서는 로그인을 테스트하고 있으며, 해당 기능은 Manage 단계에 속합니다. qa/specs/features/browser_ui/1_manage/login 내에 basic_login_spec.rb 파일을 작성하십시오.

바깥쪽 context 블록

RSpec.describe 바깥쪽 블록을 참조하십시오.

경고: 까지, RSpec 4.0 사양을 준수하기 위해 바깥쪽 context는 사용되지 않았습니다. 대신 RSpec.describe를 사용하십시오.

바깥쪽 RSpec.describe 블록

테스트는 DevOps 단계를 나타내는 바깥쪽 RSpec.describe가 있습니다.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do

  end
end

describe 블록

바깥쪽 RSpec.describe 내부에서 테스트할 기능을 설명하십시오. 이 경우 Login 입니다.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login' do

    end
  end
end

product_group 메타데이터

product_group 메타데이터를 할당하고 이 테스트가 어떤 제품 그룹에 속하는지 지정하십시오. 이 경우 authentication_and_authorization입니다.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do

    end
  end
end

it 블록 (예시)

모든 테스트 스위트에는 적어도 하나의 it 블록(예시)이 있습니다. 엔드 투 엔드 테스트를 작성하는 좋은 방법은 테스트 케이스 설명을 it 블록으로 작성하는 것입니다.

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do
      it 'can login' do

      end

      it 'can logout' do

      end
    end
  end
end

테스트 작성

중요한 질문은 “무엇을 테스트해야 하나?”이며, 더 중요한 질문은 “어떻게 테스트해야 하나?”입니다.

먼저 로그인을 시작하십시오.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do
      it 'can login' do
        Flow::Login.sign_in

      end

      it 'can logout' do
        Flow::Login.sign_in

      end
    end
  end
end

테스트를 실행한 후에 우리의 테스트는 로그인하고 종료되어야 하며, 그런 다음 “무엇을 테스트해야 하나?”라는 질문에 답해야 합니다.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do
      it 'can login' do
        Flow::Login.sign_in

        Page::Main::Menu.perform do |menu|
          expect(menu).to be_signed_in
        end
      end

      it 'can logout' do
        Flow::Login.sign_in

        Page::Main::Menu.perform do |menu|
          menu.sign_out

          expect(menu).not_to be_signed_in
        end
      end
    end
  end
end

무엇을 테스트해야 하나?

1. 로그인할 수 있는가?
2. 로그아웃할 수 있는가?

어떻게 테스트해야 하나?

1. 좌측 사이드바에 사용자 아바타가 표시되는지 확인합니다.
2. 좌측 사이드바에 사용자 아바타가 표시되지 않는지 확인합니다.

뒷단에서 be_signed_in은 사용자 아바타를 확인하는 예측 매처로, 사용자 아바타를 확인을 구현합니다.

코드 중복 제거

테스트를 리팩터링하여, sign_in 호출이 중복되고 있는 것은 before 블록을 사용하도록 변경하세요.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do
      before do
        Flow::Login.sign_in
      end

      it 'can login' do
        Page::Main::Menu.perform do |menu|
          expect(menu).to be_signed_in
        end
      end

      it 'can logout' do
        Page::Main::Menu.perform do |menu|
          menu.sign_out

          expect(menu).not_to be_signed_in
        end
      end
    end
  end
end

before 블록은 사실 before(:each)와 본질적으로 같으며, 각 예제가 실행되기 전에 실행되므로 이제 각 테스트의 시작 부분에서 로그인합니다.

리소스 및 페이지 객체를 사용한 테스트 설정

이제 로그인 이외의 다른 것을 테스트해 봅시다. 로그인이 아닌 이슈를 테스트해 봅시다. 이슈는 Plan 단계와 프로젝트 관리 그룹에 속하므로 qa/specs/features/browser_ui/2_plan/issue에 issues_spec.rb라는 파일을 생성하세요.

# frozen_string_literal: true

module QA
  RSpec.describe 'Plan' do
    describe 'Issues', product_group: :project_management do
      let(:issue) { create(:issue) }

      before do
        Flow::Login.sign_in
        issue.visit!
      end

      it 'can close an issue' do
        Page::Project::Issue::Show.perform do |show|
          show.click_close_issue_button

          expect(show).to be_closed
        end
      end
    end
  end
end

다음 중요한 사항을 참고하세요:

• 우리의 예제 시작 부분에서는 page/issue/show.rb 페이지에 있습니다.
• 테스트는 필요한 것만 필요할 때 가공합니다.
• 이슈는 시간을 절약하기 위해 API를 통해 가공되었습니다.
• GitLab은 인스턴스 변수 대신 let()을 선호합니다. 최선의 방법을 참조하세요.
• be_closed는 아직 page/project/issue/show.rb에 구현되지 않았지만, 다음 단계에서 구현됩니다.

이슈는 리소스로 가공되었으며, 이는 UI 또는 API를 통해 생성할 수 있는 GitLab 엔터티입니다. 기타 예로는 다음이 있습니다:

• 병합 요청.
• 사용자.
• 프로젝트.
• 그룹.

페이지 객체 작성

페이지 객체는 GitLab 내의 페이지를 나타내는 스위트 내의 클래스입니다. 로그인 페이지가 한 예입니다. 이미 이슈 표시 페이지 객체가 있으므로 closed? 메서드를 추가하세요.

module Page::Project::Issue
  class Show
    view 'app/views/projects/issues/show.html.haml' do
      element 'closed-status-box'
    end

    def closed?
      has_element?('closed-status-box')
    end
  end
end

다음으로 뷰 내에서 closed-status-box 요소를 정의하여 페이지 객체에서 볼 수 있도록하세요.

-#=> app/views/projects/issues/show.html.haml
.issuable-status-box.status-box.status-box-issue-closed{ ..., data: { testid: 'closed-status-box' } }

스펙 실행

스펙을 실행하기 전에 다음 사항을 확인하세요:

• GDK가 설치되어 있어야 합니다.
• GDK가 로컬에서 3000번 포트로 실행 중이어야 합니다.
• 추가적인 RSpec 메타데이터 태그가 적용되지 않았어야 합니다.
• 작업 디렉토리가 GDK GitLab 설치 내의 qa/여야 합니다.
• GitLab 인스턴스 수준의 설정이 기본 설정이어야 합니다. 기본 설정을 변경한 경우 일부 테스트에 예상치 못한 결과가 발생할 수 있습니다.
• GDK는 최초 로그인 시 비밀번호를 변경해야 하므로 root 사용자의 GDK 비밀번호를 포함해야 합니다.

스펙을 실행하려면 다음 명령을 실행하세요.

GITLAB_PASSWORD=<GDK 루트 암호> bundle exec rspec <test_file>

여기서 <test_file>은 다음 중 하나여야 합니다:

• 로그인 예제를 실행할 때 qa/specs/features/browser_ui/1_manage/login/log_in_spec.rb.
• 이슈 예제를 실행할 때 qa/specs/features/browser_ui/2_plan/issue/create_issue_spec.rb.

테스트 실행 및 가능한 옵션에 대한 추가 정보는 “QA framework README”에서 설명되어 있습니다.

엔드 투 엔드 테스트 병합 요청 템플릿

새로운 엔드 투 엔드 테스트를 제출할 때, 성공적인 병합 전에 필요한 추가 단계에 대한 정보를 포함하는 “New End to End Test” 병합 요청 설명 템플릿을 사용하세요.