• feature_flag RSpec 태그
• 선택기(Selectors) 사용
  • 이전 예시
  • 이후 예시
• 리소스 클래스 작업
  • 클린업
• 캐싱으로 인한 변덕 관리
• 피처 플래그를 사용하여 시나리오 실행
• 피처 플래그가 활성화된 상태에서 엔드 투 엔드 테스트가 통과되는지 확인
  • 피처 플래그 정의 변경 시 자동 테스트 실행
  • 피처 플래그가 활성화된 상태에서 엔드 투 엔드 테스트 실패 해결
  • 기능 개발 중 테스트 실행

피처 플래그를 사용한 테스트

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

피처 플래그를 변경하려면 관리자 권한이 필요합니다. QA::Runtime::Feature는 적절한 액세스 토큰을 제공하면(권장됨) 또는 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 환경에서 건너뛰어집니다. 이렇게 함으로써 피처 플래그 변경이 다른 테스트나 해당 환경에서 사용 중인 사용자들에게 영향을 미치는 문제를 피할 수 있습니다.
• scope를 다른 값(예: :project, :group 또는 :user) 또는 지정된 scope가 없는 경우, 또는 scope가 지정되지 않은 경우 테스트는 canary, 프로덕션 및 사전 프로덕션에서만 건너뛰어집니다. 이는 관리자 액세스를 해당 환경에서 사용할 수 없기 때문입니다.

경고: 먼저 그룹, 프로젝트, 사용자용 피처 플래그를 활성화하려고 해 보는 것이 좋습니다.

• 전역 피처 플래그를 사용해야 하는 경우에는 scope: :global을 feature_flag 메타데이터에 적용하는 것이 좋습니다. 그러나 SET는 위험 수준을 결정하기 위해 남겨둡니다.
  • 예를 들어, 테스트가 전역 피처 플래그를 사용하며 애플리케이션의 작은 영역에만 영향을 미치고 라이브 환경에서 중요한 문제들을 확인해야 하는 경우에는 이러한 시나리오에서 테스트를 건너뛰는 것이 더 위험할 수 있습니다. 이러한 경우에는 scope를 메타데이터에서 생략하여 라이브 환경에서 여전히 실행할 수 있도록 해야 합니다.

requires_admin에 대한 참고: 피처 플래그 업데이트와 관련 없는 테스트 내에서 관리자 액세스가 필요한 경우에도이 태그를 적용해야 합니다.

아래 코드는 테스트에서 작성한 프로젝트에 대해 :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)

선택기(Selectors) 사용

새로운 기능은 대부분 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를 참조하십시오.

피처 플래그가 활성화된 상태에서 엔드 투 엔드 테스트가 통과되는지 확인

피처 플래그가 Staging이나 GitLab.com에서 활성화되기 전에 엔드 투 엔드 테스트가 통과되어야 합니다. 업데이트해야 하는 테스트는 quad-planning의 일부로 식별되어야 합니다. 관련 소프트웨어 엔지니어 테스트는 테스트를 업데이트하거나 다른 엔지니어를 돕는 책임이 있습니다. 그러나 변경이 quad-planning을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 배포가 차단될 수 있습니다.

피처 플래그 정의 변경 시 자동 테스트 실행

엔드 투 엔드 테스트가 통과하는지 확인하는 두 가지 방법이 있습니다:

• Merge Request이 피처 플래그 정의 파일을 추가하거나 수정하는 경우, 두 e2e:package-and-test 작업(ee:instance-parallel 및 ee:instance-parallel-ff-inverse)이 Merge Request 파이프라인에 자동으로 포함됩니다. 하나의 작업은 기본 피처 플래그 상태로 애플리케이션을 실행하고 또 다른 작업은 그 값을 반대로 설정합니다. 그러면 동일한 테스트 스위트가 피처 플래그가 활성화되었을 때와 비활성화되었을 때 통과하는지 확인할 수 있습니다.
• 경우에 따라, 엔드 투 엔드 테스트 작업이 자동으로 트리거되지 않았거나 기본 피처 플래그 값을 사용하여 테스트를 실행했을 때(원하는 바가 아닐 수 있음), 피처 플래그를 활성화하는 Draft MR(임시 Merge Request)를 생성하여 피처 플래그가 활성화된 상태와 비활성화된 상태에서 모든 E2E 테스트가 통과하는지 확인할 수 있습니다.

피처 플래그가 활성화된 상태에서 엔드 투 엔드 테스트 실패 해결

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

• 업데이트해야 하는 테스트를 식별하고, 해당 테스트 업데이트를 담당하거나 다른 엔지니어를 돕는 관련 소프트웨어 엔지니어 테스트 담당자에게 연락할 수 있습니다. 그러나 변경 사항이 quad-planning을 거치지 않고 필요한 테스트 업데이트가 이루어지지 않으면 테스트 실패로 배포가 차단될 수 있습니다.
• 로컬에서 실패한 테스트를 기본 피처 플래그가 활성화된 상태에서 실행합니다. 이 옵션은 상당한 설정이 필요하지만, 실패한 테스트가 실행되는 동안 브라우저의 동작을 볼 수 있어 문제를 빠르게 디버깅하는 데 도움이 됩니다. 또한 지원용 E2E 테스트 문제 해결 가이드도 참고할 수 있습니다.

기능 개발 중 테스트 실행

엔드 투 엔드 테스트가 피처 플래그를 활성화한다면, Merge Request 파이프라인에서 e2e:package-and-test 작업을 실행하여 Merge Request에서 변경 내용을 테스트할 수 있습니다. 피처 플래그 및 관련 변경 사항이 이미 Merge된 경우, 기본 브랜치에서도 테스트가 통과하는지 확인할 수 있습니다. 기본 브랜치에서는 매 2시간마다 엔드 투 엔드 테스트가 실행되며 결과는 테스트케이스 세션 프로젝트에 게시됩니다.

해당 테스트가 스스로 피처 플래그를 활성화하지 않는 경우, 피처 플래그 정의 파일을 통해 기본적으로 플래그를 활성화하는 임시 Merge Request을 열어서 테스트를 업데이트해야 할지 확인할 수 있습니다. 그러면 피처 플래그 정의 변경 시 자동 테스트 실행이 자동으로 실행됩니다. 테스트가 통과하면 Merge Request을 닫을 수 있습니다. 테스트를 업데이트해야 할 경우, 관련 품질 부서의 stable 직군 상대 또는 해당 그룹의 stable 직군 상대가 없는 경우 다른 소프트웨어 엔지니어 테스트에 연락하십시오.