- 테스트 작성 전 준비 사항
- 엔드 투 엔드 테스트 필요성 판단
- DevOps 단계 식별
- 스켈레톤 테스트 생성
- 테스트 작성
- 코드를 중복 제거하기
- 리소스 및 페이지 객체를 이용한 테스트 설정
- 페이지 객체 작성하기
- 스펙 실행
- 종단 간 테스트 병합 요청 템플릿
초보자를 위한 엔드 투 엔드 테스트 작성 가이드
이 튜토리얼은 GitLab Community Edition 및 GitLab Enterprise Edition에 대한 엔드 투 엔드(e2e) 테스트 생성 과정을 안내합니다.
이 튜토리얼을 완료하면 다음을 수행할 수 있습니다:
- 엔드 투 엔드 테스트가 필요한지 결정합니다.
-
qa/내의 디렉토리 구조를 이해합니다. - 로그인 기능을 검증하는 기본 엔드 투 엔드 테스트를 작성합니다.
- 누락된 페이지 오브젝트 라이브러리를 개발합니다.
테스트 작성 전 준비 사항
테스트를 작성하기 전에 GitLab Development Kit (GDK)가 사양을 실행할 수 있도록 구성되어 있어야 합니다. 엔드 투 엔드 테스트는:
-
qa/디렉토리 내에 포함됩니다. - 독립적이며 Idempotent해야 합니다.
- 임시로 자원(예: 프로젝트, 이슈, 사용자)를 생성합니다.
- UI 및 API 인터페이스를 테스트하며, API를 사용하여 UI 테스트를 효율적으로 설정합니다.
엔드 투 엔드 테스트 필요성 판단
엔드 투 엔드 테스트를 작성하기 전에 특정 기능의 코드 커버리지를 확인합니다 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 외부 블록을 참조하세요.
경고:
외부 context는 RSpec 4.0 사양을 준수하기 위해 13.2에서 더 이상 사용되지 않습니다. 대신 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
우리는 무엇을 테스트합니까?
- 우리는 로그인 할 수 있는가?
- 우리는 로그아웃 할 수 있는가?
우리는 어떻게 테스트합니까?
- 왼쪽 사이드바에 사용자 아바타가 나타나는지 확인합니다.
- 왼쪽 사이드바에 사용자 아바타가 나타나지 않는지 확인합니다.
무대 뒤에서 be_signed_in은
프레디케이트 매처이며
사용자 아바타를 확인하는 기능을 구현합니다.
코드를 중복 제거하기
테스트 설정을 위해 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 '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 단계와 Project Management Group에 속하는 Issues를 테스트하겠습니다. 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 내의 페이지를 나타내는 클래스입니다. Login 페이지는 하나의 예입니다. Issue Show 페이지에 대한 페이지 객체가 이미 존재하므로, 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 프레임워크 README”에서 설명되어 있습니다.
종단 간 테스트 병합 요청 템플릿
새로운 종단 간 테스트를 제출할 때는 “새 종단 간 테스트” 병합 요청 설명 템플릿을 사용하여 성공적인 병합을 위해 필요한 추가 단계를 포함하세요.
도움말