답변.

자동 테스트의 적절한 버전 관리 및 통합은 프로젝의 현재 상태와의 일치성을 보장하는 데 매우 중요합니다.

질문 배경

자동 테스트는 처음에 종종 주요 프로젝트와 별도로 관리되어 호환성 문제 및 유지 관리 문제를 초래했습니다. 여러 브랜치의 발전, 잦은 소프트웨어 및 테스트 릴리스는 공통 버전 관리 시스템의 필요성을 낳았습니다.

문제

버전 관리 및 합의된 통합이 없으면 다음과 같은 문제가 발생합니다:

• 변경된 소프트웨어에서 비 актуальные 테스트 실행
• 테스트 변경 사항을 고려하지 않은 새로운 기능의 배포 시 테스트 "중단"
• CI/CD의 실패

해결 방법

현대적인 접근 방법:

• 테스트는 일반적인 버전 관리 시스템(주로 git)에 저장됩니다.
• 테스트 브랜치는 소프트웨어 개발 브랜치에 연결됩니다: 기능 브랜치에서 테스트와 코드는 함께 진행됩니다.
• 자동 검토/빌드는 풀 리퀘스트 처리 시 수행됩니다.
• 테스트 및 코드 변경 사항에 대한 검토 및 합의

# 일반적인 접근 방법:
git checkout -b feature/new_login
# 기능과 테스트는 함께 개발되고 테스트됩니다.
# 검토 후 기본 브랜치에 함께 병합됩니다.

주요 특징:

• 코드 및 테스트의 변경 사항 일관성(비동기화 없음)
• 편리한 롤백 및 버전 비교(git history 통해)
• 팀 작업 및 자동 테스트의 코드 리뷰 가능성

속임수 문제가 있는 질문들.

테스트를 프로젝트 코드와 별도의 리포지토리에 저장할 수 있습니까?

네, 하지만 이 경우 테스트의 현재 상태를 유지하기가 더 어려워지며, 수동 동기화가 필요하고 릴리스나 버그 수정 시 무언가를 "잊어버릴" 위험이 있습니다.

PR 생성 시 테스트가 즉시 모든 새로운 기능을 커버해야 합니까?

이론적으로는 그렇지만 실질적으로는 첫 번째 PR에서 MVP/기본 시나리오를 커버하고 복잡한 사례는 별도의 작업으로 다루는 경우가 많습니다. 중요한 것은 필수 기능이 즉시 커버되어야 한다는 것입니다.

코드 롤백 없이 테스트 만을 롤백할 수 있습니까?

테스트와 코드가 동일한 브랜치에 있는 경우 롤백이 가능합니다. 그러나 코드를 동반하지 않고 테스트를 "롤백"하는 것은 피하는 것이 좋습니다: 이는 검사의 품질을 저하시킵니다.

전형적인 오류 및 안티 패턴

• 테스트를 git이 아닌 파일 시스템에 저장하는 것
• 프로젝트와의 명확한 연결 없이 별도의 리포지토리에서 테스트 유지
• 코드와 동시에가 아니라 외부에서 테스트를 합치는 것(post factum)

실제 사례

부정적 케이스

테스트가 별도의 리포지토리인 프로젝트. 릴리스 후 프로그래머들이 테스트를 "잊어버려" 테스트가 실패하고, 비 актуальные 검사를 통과하며, 배포 환경에서 버그를 잡았습니다.

장점:

• 프로그래머들은 QA와 독립적으로 작업할 수 있었습니다.

단점:

• 동기화에 소요되는 시간, "구식" 테스트의 존재

긍정적 케이스

테스트와 프로젝트 코드는 동일한 git 브랜치에서 관리됩니다: 새로운 풀 리퀘스트가 있을 때마다 자동 테스트가 추가된 코드에 대해 반드시 업데이트됩니다. 모든 변경 사항은 코드 리뷰 및 자동 검사를 거칩니다.

장점:

• 테스트 품질에 대한 빠른 피드백
• 변경 사항의 완전한 일관성

단점:

• 팀워크 및 리뷰에 대한 정직한 규율이 필요합니다.