조직으로 테스트 작성

조직으로 테스트 작성에 대해 설명합니다.

조직 격리: "공통 조직" # 대부분의 경우 기능은 조직 경계를 넘지 않습니다. 이는 테스트도 하나의 조직 내에 포함되어야 함을 의미합니다. 그리고 생성된 데이터는 동일한 조직을 공유해야 합니다. 하지만 개발자가 데이터가 동일한 조직의 일부인지 수동으로 확인해야 하는 것을 피하고 싶습니다. 이를 위해 common_organization 을 도입했습니다. organization 속성의 기본값으로 사용할 수 있습니다: FactoryBot .define do factory :sbom_component , class: 'Sbom::Component' do organization { association :common_organization } end end 공통 조직을 사용하는 팩토리들은 동일한 조직을 공유합니다: context 'when factories use common_organization as default' do let( :user ) { create( :user ) } let( :project ) { create( :project ) } let( :sbom_component ) { create( :sbom_component ) } it 'is the same organization' do expect(sbom_component.organization).to eq(project.organization) expect(user.organization).to eq(project.organization) end end organizations 테이블과의 관계가 있는 대부분의 팩토리는 이미 이를 사용하고 있습니다. 누락된 팩토리에는 추가되어야 합니다. 사용자 생성 # Cells의 첫 번째 반복에서 사용자는 하나의 조직에만 속합니다. 그러나 데이터베이스 설계는 여러 조직의 멤버십을 지원합니다. 이로 인해 User 인스턴스에는 조직과 관련된 두 가지 메서드가 있습니다: organizations : 사용자가 멤버인 조직들. organization : 샤딩 키: 사용자를 '소유하는' 조직. 몇 가지 예시: # 공통 조직의 사용자 생성 let( :user1 ) { create( :user ) } # 다른 조직의 사용자 생성 let( :user2 ) { create( :user , organization: other_organization) } # 두 조직 모두의 사용자 생성, org1이 샤딩 키로 사용됨 let( :user3 ) { create( :user , organizations: [org1, org2])} Note 일부 특수한 경우를 제외하고는 사용자의 여러 조직 멤버십을 테스트할 필요가 없습니다. Current.organization 에 의존하는 코드에 대한 테스트 작성 # 테스트에 Current.organization 이 필요한 경우 with_current_organization 공유 컨텍스트를 사용할 수 있습니다. 이렇게 하면 Gitlab::Current::Organization 클래스에서 반환될 current_organization 메