- 테스트를 작성하기 전에
- 끝에서 끝 테스트가 필요한지 여부 판단하기
- DevOps 단계 식별하기
- 스켈레톤 테스트 생성하기
- 테스트 작성
- 코드 중복 제거
- 리소스 및 페이지 오브젝트를 사용한 테스트 설정
- 페이지 오브젝트 작성
- 스펙 실행
- 엔드 투 엔드 테스트 병합 요청 템플릿
새로운 기능을 테스트하는 초보자 안내서
이 자습서는 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
무엇을 테스트해야 하는가?
- 우리는 로그인 할 수 있는가?
- 우리는 로그아웃 할 수 있는가?
어떻게 테스트해야 하는가?
- 좌측 사이드바에 사용자 아바타가 나타나는지 확인합니다.
- 좌측 사이드바에 사용자 아바타가 나타나지 않는지 확인합니다.
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” 병합 요청 설명 템플릿을 사용하여 성공적인 병합 이전에 필요한 추가 단계를 따르세요.