자동 테스트와 품질 게이트
5. 자주 하는 실수 (Tip)
❌ 실수 1. 테스트 없이 커밋하고 나중에 몰아서 작성
기능이 다 끝난 뒤 테스트를 몰아 쓰면 이미 버그가 배포됐거나, 테스트가 코드에 억지로 맞춰집니다. 코드와 테스트를 같은 커밋에 넣는 습관이 낫습니다.
❌ 실수 2. 단위 테스트 없이 E2E 만 잔뜩 작성
E2E 는 느리고 환경 의존적이라 자주 실패합니다. 실패 원인을 찾는 데도 오래 걸려 피라미드 아래층부터 채워야 합니다.
❌ 실수 3. -Werror 없이 경고를 방치
경고가 쌓이면 진짜 문제가 섞여도 아무도 안 읽습니다. 처음부터 -Werror 로 경고 0건을 유지하는 편이 관리하기 쉽습니다.
❌ 실수 4. 실패한 테스트를 @Disabled 로 덮음
당장 급해서 끄면 그 테스트가 지키던 동작은 더 이상 검증되지 않습니다. 원인을 고치거나, 못 고치면 이슈로 남기고 기한을 정합니다.
❌ 실수 5. 종료 코드만 보고 리포트를 안 읽음
종료 코드 1 은 "무언가 실패했다" 만 알려 줍니다. 어떤 테스트가 왜 실패했는지는 리포트나 콘솔 출력을 봐야 압니다.
❌ 실수 6. 커버리지 숫자를 목표로 삼음
숫자를 올리려 의미 없는 테스트를 추가하면 커버리지는 오르지만 버그는 못 잡습니다. 커버리지는 결과 지표지 목표가 아닙니다.
❌ 실수 7. 정적 검사를 로컬에서만 실행
로컬 IDE 에서만 경고를 보면 사람마다 확인 여부가 다릅니다. 파이프라인 스텝으로 넣어야 모두에게 같은 기준이 적용됩니다.
❌ 실수 8. 게이트 기준 없이 "테스트만 통과하면 OK"
테스트는 통과했지만 경고가 잔뜩인 코드도 병합됩니다. 테스트·정적 검사·커버리지 기준을 미리 문서로 정해 둬야 합니다.
❌ 실수 9. 상태 검사만 설정하고 브랜치 보호를 안 켬
Checks 탭에 결과는 뜨지만 필수로 지정하지 않으면 실패해도 병합 버튼이 막히지 않습니다. 브랜치 보호 규칙에서 반드시 필수로 지정합니다.
❌ 실수 10. 경고를 정보성 메시지로 착각
-Xlint 경고를 "그냥 알림" 으로 넘기면 실제로 널 포인터나 타입 문제로 이어지는 경우가 많습니다. -Werror 로 강제하지 않더라도 정기적으로 읽어야 합니다.