- 테스트를 작성하기 전에
- 엔드 투 엔드 테스트가 필요한지 확인
- DevOps 단계 식별
- 뼈대 테스트 생성
- 테스트 작성
- 코드 중복 제거
- 리소스 및 페이지 객체를 사용한 테스트 설정
- 페이지 객체 작성
- 스펙 실행
- 엔드 투 엔드 테스트 Merge Request 템플릿
엔드 투 엔드 테스트 작성 초보자 가이드
이 튜토리얼은 GitLab Community Edition 및 GitLab Enterprise Edition용 엔드 투 엔드 (e2e) 테스트 작성을 안내합니다.
이 튜토리얼이 끝날 때까지 다음을 할 수 있을 것입니다:
- 엔드 투 엔드 테스트가 필요한지 여부를 결정합니다.
-
qa/디렉터리 내의 디렉터리 구조를 이해합니다. - 로그인 기능을 검증하는 기본 엔드 투 엔드 테스트를 작성합니다.
- 누락된 페이지 오브젝트 라이브러리를 개발합니다.
테스트를 작성하기 전에
테스트를 작성하기 전에 귀하의 GitLab Development Kit (GDK)가 구성되어 특정 사양을 실행할 수 있어야 합니다. 엔드 투 엔드 테스트:
-
qa/디렉터리 내에 포함됩니다. - 독립적이어야 하며 멱등성을 가져야 합니다.
- 자원 (프로젝트, 이슈, 사용자 등)을 필요에 따라 만들어야 합니다.
- UI 및 API 인터페이스를 테스트하고 API를 사용하여 UI 테스트를 효율적으로 설정해야 합니다.
엔드 투 엔드 테스트가 필요한지 확인
GitLab 프로젝트에 대한 특정 기능의 코드 커버리지를 확인한 후에 엔드 투 엔드 테스트를 작성해야 합니까? 단위, 기능 또는 통합 수준에서 충분한 테스트 커버리지가 있는지 확인하십시오. 그렇다고 답했다면 엔드 투 엔드 테스트가 필요하지 않습니다.
GitLab에서 테스트 수준 분포에 대한 자세한 정보는 테스팅 수준을 참조하십시오.
- 올바른 수준에서 테스트하는 방법 섹션의 테스팅 수준 문서를 참조하십시오.
- 기능이 얼마나 자주 변경되는지 확인하십시오. 자주 변경되지 않는 안정적인 기능은 이미 하위 수준 테스트에서 처리되었다면 엔드 투 엔드 테스트로 처리할 가치가 없을 수 있습니다.
- 마지막으로, 해당 기능을 구현하고 낮은 수준의 테스트에 관여하는 개발자들과 제안된 테스트에 대해 논의하십시오.
이 튜토리얼에서는 엔드 투 엔드 로그인 테스트를 작성하고 있지만, 이미 충분히 하위 수준 테스트로 처리되었기 때문에, 대부분의 엔드 투 엔드 흐름에 대한 첫 단계이며 가장 이해하기 쉽기 때문에 작성합니다.
DevOps 단계 식별
GitLab QA 엔드 투 엔드 테스트는 DevOps 라이프사이클의 다른 단계로 구성됩니다. 테스트를 단계에 따라 어디에 배치해야 하는지, 테스트가 속하는 기능은 무엇인지 확인한 후 해당 단계의 하위 디렉터리에 배치합니다.
테스트가 엔터프라이즈 에디션 전용인 경우, 해당 테스트는 features/ee 디렉터리에 생성되지만, 동일한 DevOps 라이프사이클 형식을 따릅니다.
뼈대 테스트 생성
이 튜토리얼의 첫 부분에서는 로그인을 테스트하고 있으며, 이는 Manage 단계에 속합니다. qa/specs/features/browser_ui/1_manage/login 내부에 basic_login_spec.rb 파일을 생성합니다.
외부 context 블록
RSpec.describe 외부 블록을 확인하십시오.
외부 RSpec.describe 블록
테스트에는 DevOps 단계를 나타내는 외부 RSpec.describe가 있습니다.
# frozen_string_literal: true
module QA
RSpec.describe 'Manage' do
end
end
describe 블록
외부 RSpec.describe 내부에서 테스트할 기능을 설명합니다. 이 경우 로그인입니다.
# 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은 사실 사용자 아바타를 확인하는 예측 매처입니다.
코드 중복 제거
중복되는 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 엔터티입니다. 다른 예시로는 다음이 있습니다.
- Merge Request.
- 사용자.
- 프로젝트.
- 그룹.
페이지 객체 작성
페이지 객체는 GitLab 내의 페이지를 나타내는 스위트 내의 클래스입니다. Login 페이지는 하나의 예시가 될 것입니다. 이슈 표시 페이지에 대한 페이지 객체가 이미 존재하므로 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”에서 설명되어 있습니다.
엔드 투 엔드 테스트 Merge Request 템플릿
새로운 엔드 투 엔드 테스트를 제출하는 경우 “새 엔드 투 엔드 테스트” Merge Request 설명 템플릿을 사용하여 성공적인 Merge 이전에 필요한 추가 단계를 따르세요.
도움말