• feature_flag RSpec 태그
• 셀렉터 사용하기
  • 예시 (변경 전)
  • 예시 (변경 후)
• 리소스 클래스 사용하기
  • 정리
• 캐싱으로 인한 불안정성 관리
• 기능 플래그가 활성화된 상황에서 시나리오 실행
• 기능 플래그가 활성화된 상태에서 end-to-end 테스트가 통과되는지 확인
  • 기능 플래그 정의가 변경될 때 자동 테스트 실행
  • 기능 플래그가 활성화된 상태로 end-to-end 테스트 실패 해결
  • 기능 개발 중인 테스트 실행

특징 플래그로 테스트하기

특징 플래그를 활성화하여 특정 테스트를 실행하려면 QA::Runtime::Feature 클래스를 사용하여 특징 플래그를 활성화 및 비활성화할 수 있습니다 (API를 통해).

특징 플래그를 변경하려면 관리자 권한이 필요합니다. QA::Runtime::Feature는 적절한 액세스 토큰을 제공하면 (권장됨) GITLAB_QA_ADMIN_ACCESS_TOKEN을 통해 관리자로 자동 인증되거나 GITLAB_ADMIN_USERNAME 및 GITLAB_ADMIN_PASSWORD를 제공하면 관리자로 자동 인증됩니다.

feature_flag RSpec 태그

테스트가 적절한 환경에서 건너뛸 수 있도록 feature_flag 태그를 포함해야 합니다.

필수 메타데이터:

name

• 형식: feature_flag: { name: 'feature_flag_name' }
• 정보 제공을 위해 사용됩니다. 테스트하는 특징 플래그를 결정하기 위해 포함되어야 합니다.

선택적 메타데이터:

scope

• 형식: feature_flag: { name: 'feature_flag_name', scope: :project }
• scope가 :global로 설정된 경우 테스트는 모든 라이브 .com 환경에서 건너뛰어집니다. 이는 특징 플래그 변경이 다른 테스트나 해당 환경의 사용자에게 영향을 미치는 문제를 피하기 위한 것입니다.
• 다른 값 (예: :project, :group 또는 :user)으로 scope가 설정된 경우 또는 scope가 지정되지 않은 경우 테스트는 canary, production, 및 pre-production에서만 건너뜁니다.

경고: 먼저 그룹, 프로젝트, 사용자를 위해 특징 플래그를 활성화하려고 시도하는 것이 좋습니다. - 전역 특징 플래그를 사용해야 하는 경우 feature_flag 메타데이터에 scope: :global을 적용하는 것이 좋습니다. 하지만, 이는 SET의 재량에 따라 위험 수준을 결정합니다. - 예를 들어, 어떤 테스트가 응용 프로그램의 작은 영역에만 영향을 주는 전역 특징 플래그를 사용하며 라이브 환경에서 중요한 문제를 확인해야 하는 경우가 있습니다. 이러한 시나리오에서는 테스트 실행을 건너뛰는 것이 더 위험할 수 있습니다. 이런 경우 메타데이터에서 scope를 생략하여 라이브 환경에서도 테스트를 실행할 수 있도록 남겨둘 수 있습니다.

requires_admin에 대한 참고: 이 태그는 특징 플래그를 업데이트하는 것과 관계없는 테스트 내의 다른 동작에도 관리자 액세스가 필요한 경우에도 여전히 적용되어야 합니다 (예: API를 통해 사용자를 생성하는 등).

아래 코드는 테스트에서 생성된 프로젝트에 :feature_flag_name라는 이름의 특징 플래그를 활성화합니다:

RSpec.describe "특징 플래그 활성화", feature_flag: {
  name: 'feature_flag_name',
  scope: :project
  } do

  let(:project) { Resource::Project.fabricate_via_api! }

  around do |example|
    Runtime::Feature.enable(:feature_flag_name, project: project)
    example.run
    Runtime::Feature.disable(:feature_flag_name, project: project)
  end

  it "특징 플래그 테스트" do
    # 특징 플래그를 활성화하여 테스트를 실행합니다.
    # 이는 이 테스트에서 생성된 프로젝트에만 영향을 줍니다.
  end
end

enable 및 disable 메서드는 먼저 플래그를 설정한 후 API에서 업데이트된 값을 확인합니다.

마찬가지로, 그룹, 사용자 또는 특징 그룹에 대한 특징을 활성화할 수 있습니다:

group = Resource::Group.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, group: group)

user = Resource::User.fabricate_via_api!
Runtime::Feature.enable(:feature_flag_name, user: user)

feature_group = "a_feature_group"
Runtime::Feature.enable(:feature_flag_name, feature_group: feature_group)

scope가 제공되지 않으면 특징 플래그가 인스턴스 전체에 설정됩니다:

# 이는 모든 사용자에게 영향을 줍니다!
Runtime::Feature.enable(:feature_flag_name)

셀렉터 사용하기

새로운 기능은 대부분의 경우 vue 컴포넌트 또는 haml 파일을 새 파일로 대체합니다. 대부분의 경우, 새 파일 또는 컴포넌트는 특징 플래그로만 접근할 수 있습니다. 이 방법은 테스트가 특징 플래그를 사용하고 사용하지 않는 두 가지 경우 모두 통과해야 할 때 문제가 됩니다. 테스트가 두 경우 모두 통과하려면:

1. 새 컴포넌트 또는 파일 내에 다른 셀렉터를 만듭니다.
2. 이전 것과 동일한 이름을 지정합니다.

셀렉터는 페이지 오브젝트의 특정 프론트엔드 파일에 연결되어 있으며 qa:selectors 테스트 내에서 사용 가능한지 확인됩니다. 언급된 셀렉터가 해당 프론트엔드 파일에 누락되어 있는 경우 테스트가 실패합니다. 특징 플래그가 활성화되거나 비활성화될 때 셀렉터를 사용할 수 있도록 하려면 새 셀렉터를 페이지 오브젝트에 추가하고 이전 셀렉터는 그대로 둡니다. 이렇게 하면 테스트가 올바른 셀렉터를 사용하고 누락된 셀렉터를 감지합니다.

기존 프론트엔드 파일을 변경하여 새로운 기능이 이미 있는 셀렉터를 변경해야 하는 경우, 동일한 이름의 새 셀렉터를 추가할 수 있습니다. 그러나 페이지에는 표시되는 셀렉터 중 하나만 있어야 합니다. 따라서 다음을 수행해야 합니다:

1. 특징 플래그로 다른 셀렉터를 비활성화합니다.
2. 특징 플래그에서 해당 셀렉터를 제거할 때 이전 셀렉터를 프론트엔드 파일과 페이지 오브젝트 파일에서 삭제하기 위해 주석을 추가합니다.

예시 (변경 전)

# 이것은 이전 파일에 대한 링크입니다
view 'app/views/devise/passwords/edit.html.haml' do
  # 새 셀렉터는 동일한 이름을 가져야 합니다.
  element 'password-field'
  ...
end

예시 (변경 후)

view 'app/views/devise/passwords/edit.html.haml' do
  element 'password-field'
  ...
end

# 이제 셀렉터의 사용 가능 여부를 확인할 수 있습니다
view 'app/views/devise/passwords/new_edit_behind_ff.html.haml' do
  # 셀렉터는 동일한 이름을 가집니다
  element 'password-field'
end

리소스 클래스 사용하기

리소스 클래스가 특징 플래그가 활성화되어 있는 경우 다르게 동작해야 한다면 클래스 내부에 특징 플래그의 이름을 가진 변수를 토글하세요. 이 변수와 조건은 모든 동작이 적절하게 처리되도록 합니다.

이 변수를 fabricate_via_api 호출 내부에서 설정할 수 있습니다. 일관된 방식을 위해 다음을 사용합니다:

• 비활성화된 것이 아니라 활성화가 되었는지 검사합니다.
• 변수 이름 뒤에 activated라는 단어를 추가합니다.
• initialize 메서드 내부에서 변수의 기본값을 설정합니다.

예를 들어:

def initialize
  name_of_the_feature_flag_activated = false
  ...
end

정리

기능 플래그를 제거한 후에 리소스 클래스를 정리하고 변수를 삭제하십시오. 모든 메소드는 이제 기본 상태의 조건 절차를 사용해야 합니다.

캐싱으로 인한 불안정성 관리

모든 응용 프로그램 설정 및 모든 기능 플래그는 GitLab 내에서 1분 동안 캐시됩니다. 테스트 중에는 모든 캐싱이 비활성화되지만 정적 환경에서는 예외입니다.

테스트가 기능 플래그를 변경하면 요소가 활성 기능 플래그로만 표시되는 경우 불안정한 동작을 일으킬 수 있습니다. 이러한 동작을 우회하려면 기능 플래그 뒤에 있는 요소를 기다리는 것을 추가하십시오.

기능 플래그가 활성화된 상황에서 시나리오 실행

기존 테스트를 편집할 필요 없이 기능 플래그가 활성화된 상태에서 전체 시나리오를 실행하는 것도 가능합니다.

세부 내용은 QA README를 참조하십시오.

기능 플래그가 활성화된 상태에서 end-to-end 테스트가 통과되는지 확인

Staging 또는 GitLab.com에서 활성화되기 전에 end-to-end 테스트는 기능 플래그가 활성화된 상태로 통과해야 합니다. 업데이트해야 할 테스트는 quad-planning의 일부로 식별되어야 합니다. 관련된 소프트웨어 엔지니어 테스트 담당자는 테스트를 업데이트하거나 다른 엔지니어를 지원하는 데 책임이 있습니다. 그러나 변경사항이 quad-planning을 거치지 않고 필요한 테스트 업데이트가 이뤄지지 않으면 테스트 실패로 배포가 차단될 수 있습니다.

기능 플래그 정의가 변경될 때 자동 테스트 실행

end-to-end 테스트가 통과되는 두 가지 방법이 있습니다.

• 만약 병합 요청이 기능 플래그 정의 파일을 추가하거나 편집한다면, 두 개의 e2e:test-on-omnibus 작업 (ee:instance-parallel 및 ee:instance-parallel-ff-inverse)이 병합 요청 파이프라인에 자동으로 포함됩니다. 하나의 작업은 기본 기능 플래그 상태로 응용 프로그램을 실행하고 다른 하나는 그 상태의 역을 설정합니다. 이러한 작업은 기능 플래그가 활성화되었을 때 또는 비활성화되었을 때 동일한 테스트 모음을 실행하여 해당 테스트가 통과하는지 확인합니다.
• 경우에 따라서 end-to-end 테스트 작업이 자동으로 트리거되지 않았거나, 기본 기능 플래그 값(원하는 결과가 아닐 수 있음)으로 테스트를 실행했다면 기능 플래그를 활성화하는 Draft MR을 만들어 모든 E2E 테스트가 기능 플래그를 활성화하고 비활성화할 때 모두 통과하는지 확인할 수 있습니다.

기능 플래그가 활성화된 상태로 end-to-end 테스트 실패 해결

기능 플래그를 활성화하면 E2E 테스트가 실패할 경우, 실패한 파이프라인의 아티팩트를 검색하여 실패한 테스트의 스크린샷을 볼 수 있습니다. 그 후에 다음 중 하나를 할 수 있습니다.

• 업데이트해야 할 테스트를 식별하고 그 작업에 대한 업데이트에 책임이 있는 관련 소프트웨어 엔지니어 테스트 담당자에게 연락하십시오. 그러나 변경사항이 quad-planning을 거치지 않고 필요한 테스트 업데이트가 이뤄지지 않으면 테스트 실패로 배포가 차단될 수 있습니다.
• 사전에 설정에 상당한 양의 시간이 필요하지만, 실패한 테스트를 실행하여(https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa#run-the-end-to-end-tests-in-a-local-development-environment)와 함께 기능 플래그를 활성화한 상태에서 로컬에서 실행할 수 있습니다. 이렇게 하면 브라우저가 실패한 테스트를 실행하는 동안의 상황을 더 빠르게 디버깅하는 데 도움이 되는 문제를 확인할 수 있습니다. 또한 E2E 테스트에 대한 문제 해결 가이드를 참조하여 일반적인 차단 요소에 대한 지원을 받을 수 있습니다.

기능 개발 중인 테스트 실행

end-to-end 테스트가 기능 플래그를 활성화하면 병합 요청 파이프라인에서 e2e:test-on-omnibus 작업을 실행하여 병합 요청에서 변경 내용을 테스트할 수 있습니다. 기능 플래그와 관련 변경 사항이 이미 병합된 경우, 기본 브랜치에서 테스트가 통과하는지 확인할 수 있습니다. end-to-end 테스트는 기본 브랜치에서 매 2시간마다 실행되며 결과는 테스트 세션 보고서에 게시됩니다.

만약 관련 테스트가 스스로 기능 플래그를 활성화하지 않는다면, 기능 플래그 정의 파일을 통해 기본적으로 기능 플래그를 활성화하는 Draft MR을 여는 것으로 해당 테스트가 업데이트가 필요한지 확인할 수 있습니다. 이렇게 하면 end-to-end 테스트 모음이 자동으로 실행됩니다. 테스트가 통과하면 병합 요청을 닫을 수 있습니다. 테스트를 업데이트하는 데 도움이 필요한 경우 관련 Quality 부서에서 안정적인 대응 상대 또는 귀하의 그룹에 안정적인 대응 상대가 없는 경우 다른 소프트웨어 엔지니어 테스트에게 연락하십시오.