GitLab 테스트 전략

GitLab 개발 가이드라인 - 테스트 전략

핵심 원칙 # 빠른 피드백 가장 관련성 높은 테스트를 먼저 실행하여 속도를 우선시하십시오 — 빠르게 실패하고, 빠르게 수정하십시오. 점진적 테스트 좁게 시작하고 넓게 확장하십시오. 점진적인 커버리지를 통해 신뢰를 쌓으십시오. 리소스 효율성 모든 테스트는 존재 이유를 가져야 합니다. 중복 없음, 낭비 없음. 명확한 소유권 모든 테스트 스위트에는 소유자가 필요합니다. 정의되지 않은 책임은 쇠퇴로 이어집니다. 테스트 안정성 테스트가 머지, 배포 또는 릴리스를 안정적으로 차단할 수 없다면 존재해서는 안 됩니다. 수정하거나 삭제하십시오. 테스트 스위트 배치 가이드라인 # Note 테스트 피라미드에 대한 자세한 내용은 테스트 수준 을, 머지 요청 파이프라인 단계 이해는 파이프라인 단계 를 참조하십시오. 테스트 유형 목적 실행 시기 차단 단위 테스트 개별 구성 요소를 격리하여 검증 모든 MR 파이프라인(1단계에서는 예측, 2단계 이상에서는 전체 스위트) 예 통합 테스트 구성 요소 간 상호 작용 확인 2단계 이상 MR, 안정 브랜치, 배포 2단계 이상에서 예 시스템/기능 테스트 UI를 통해 단일 기능의 기능을 검증 2단계 이상 MR, 안정 브랜치 2단계 이상에서 예 엔드투엔드(E2E) 테스트 전체 중요 사용자 여정 검증 • 스모크: 배포 파이프라인, 기능 플래그 전환 • 전체: 3단계 MR, 예약된 파이프라인 3단계에서 예, 스모크 테스트는 배포 차단 파이프라인 유형 요구사항 # 머지 요청 파이프라인 # 단계 프론트엔드 변경 백엔드 변경 데이터베이스 변경 1단계 Jest 예측만 RSpec 예측만 마이그레이션 테스트 + 예측 2단계 전체 Jest 스위트 + 선택적 E2E 전체 RSpec 단위/통합 + 선택적 E2E 전체 테스트 스위트 3단계 전체 Jest + E2E 전체 RSpec + E2E 전체 스위트 + E2E 배포 파이프라인 # 단계 필요한 테스트 차단 스테이징 E2E 스모크 스위트 ✅ 카나리 E2E 스모크 스위트 ✅ 프로덕션 배포 후 스모크 ❌ 안정/보안 브랜치 # 파이프라인 유형 프론트엔드 백엔드 데이터베이스 E2E 백포트 MR 전체 Jest 스위트 전체 RSpec 단위/통합 마이그레이션, DB 스키마 확인 Omnibus 및 GDK에서 전체 스위트 안정/ 보안 브랜치 (병합 후) Jest 단위/통합 RSpec 단위/통합/시스템 마이그레이션 및 백그라운드 마이그레이션 테스트 없음 개발 워크플로 # 새 테스트 추가 # 테스트 유형 선택 가능한 가장 낮은 수준에서 시작하십시오: 단위 → 통합 → 시스템 → E2E. 커버리지 평가 새 테스트를 작성하기 전에 기존 테스트를 검색하십시오. 같은 것을 두 번 테스트하지 마십시오. 스위트 배치 올바른 스위트 및 단계에 테스트를 맞추십시오. 확립된 패턴을 따르십시오. 기본적으로 차단 새 테스트는 _기본적으로 차단_합니다. 비차단 테스트는 예외이지 규칙이 아닙니다. 파이프라인에서 테스트 실행 수정 # 왼쪽으로 이동 가능하면 파이프라인에서 테스트를 더 일찍 이동하십시오. 더 빠른 피드백은 시간을 절약합니다. 차단