테스트 가이드라인

테스트 가이드라인에 대해 설명합니다.

이 페이지는 GitLab의 인증 변경에 대한 정책 사양을 작성하는 방법에 대한 지침을 제공합니다. 단위 테스트는 spec/policies/ 및 ee/spec/policies/ 에 있습니다. 구조 # 권한당 하나의 describe 블록 # 각 권한에는 자체 describe 블록이 있어야 합니다. 여러 권한을 단일 블록으로 그룹화하지 마십시오 — 이렇게 하면 실패한 테스트가 어떤 권한과 관련이 있는지 식별하기 어려워집니다. # 나쁜 예 - 한 블록에 여러 권한 describe 'read and update issue' do it { is_expected.to be_allowed( :read_issue , :update_issue ) } end # 좋은 예 - 권한당 하나의 블록 describe 'read_issue' do # ... end describe 'update_issue' do # ... end 역할 기반 확인에 테이블 구문 사용 # where 테이블 구문을 사용하여 각 역할을 명시적으로 테스트하십시오. 이렇게 하면 어떤 역할이 액세스 권한을 가지고 어떤 역할이 없는지 즉시 명확해지고, 반복적인 it 블록을 피할 수 있습니다. describe 'read_vulnerability' do where( :current_user , :allowed ) do ref( :guest ) | false ref(:planner) | false ref( :reporter ) | false ref(:developer) | true ref( :maintainer ) | true ref(:auditor) | false ref( :owner ) | true ref(:admin) | true end end 항상 테이블에 모든 역할을 포함하십시오 — 허용되지 않을 것으로 예상되는 역할을 생략하지 마십시오. 명시적인 false 값은 true 값만큼 중요한데, 의도된 액세스 경계를 문서화하기 때문입니다. 모든 블록에서 주제 지정 # let_it_be 를 사용하여 각 describe 블록 내에서 주제를 명시적으로 정의하십시오. 상위 범위에서 정의된 주제에 의존하지 마십시오 — 이렇게 하면 우발적인 테스트 오염을 방지하고 각 블록을 자체 포함으로 만듭니다. # 나쁜 예 - 최상위 수준에서 주제가 정의되고 모든 블록에서 공유됨 let_it_be( :project ) { create( :project ) } describe 'read_vulnerability' do # 위의 project를 암묵적으로 사용 end # 좋은 예 - 각 블록 내에서 주제가 정의됨 describe 'read_vulnerability' do let_it_be( :project ) { private_project } where( :current_user , :allowed ) do # ... end end 일반적인 project 보다는 테스트 중인 가시성이나 상태를 반영하는 설명적인 이름의 프로젝트 픽스처( private_project , public_project , archived_projec