• 테스트를 작성하기 전에
• 끝에서 끝 테스트가 필요한지 여부 판단하기
• 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 테스트를 효율적으로 설정해야 합니다.

참고: 자세한 정보는 End-to-end testing Best Practices를 참조하십시오.

끝에서 끝 테스트가 필요한지 여부 판단하기

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

GitLab에서 각 수준별로 테스트 분포에 대한 정보는 Testing Levels를 참조하십시오.

• 올바른 수준에서 테스트하는 방법? 섹션의 Testing levels 문서를 확인하십시오.
• 기능이 얼마나 자주 변경되는지 확인하십시오. 자주 변경되지 않는 안정적인 기능은 이미 하위 수준 테스트에서 처리되었다면 끝에서 끝 테스트로 더 다룰 가치가 없을 수 있습니다.
• 마지막으로, 기능을 구현하고 하위 수준 테스트를 수행하는 개발자들과 해당 테스트에 대해 논의하십시오.

경고: 이 기능에 대해 이전에 작성된 테스트를 확인하려면 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 외부 블록을 확인하십시오.

경고: 외부 context는 13.2 버전에서 폐기되었습니다, RSpec 4.0 사양을 준수하기 위해 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 '로그인 할 수 있어야 합니다' do

      end

      it '로그아웃 할 수 있어야 합니다' do

      end
    end
  end
end

테스트 작성

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

로그인부터 시작합니다.

# frozen_string_literal: true

module QA
  RSpec.describe 'Manage' do
    describe 'Login', product_group: :authentication do
      it '로그인 할 수 있어야 합니다' do
        Flow::Login.sign_in

      end

      it '로그아웃 할 수 있어야 합니다' 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 '로그인 할 수 있어야 합니다' do
        Flow::Login.sign_in

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

      it '로그아웃 할 수 있어야 합니다' 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은 predicate matcher로, 유저 아바타를 확인하는 기능을 구현합니다.

코드 중복 제거

테스트를 리팩터링하여 테스트 설정에 before 블록을 사용하도록 하여 sign_in 호출을 중복되지 않도록 합니다.

# frozen_string_literal: true

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

      it '로그인 할 수 있어야 합니다' do
        Page::Main::Menu.perform do |menu|
          expect(menu).to be_signed_in
        end
      end

      it '로그아웃 할 수 있어야 합니다' 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 '이슈를 닫을 수 있어야 합니다' 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 root password> 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” 병합 요청 설명 템플릿을 사용하여 성공적인 병합 이전에 필요한 추가 단계를 따르세요.