자동 테스트와 품질 게이트

2. 핵심 원리

2.1 테스트 피라미드

테스트는 범위가 넓을수록 느리고 불안정합니다. 아래로 갈수록 많이, 위로 갈수록 적게 만드는 것이 기본 원칙입니다.

2.2 JUnit 콘솔 런처로 실행하기

Gradle·Maven 없이도 junit-platform-console-standalone jar 하나로 테스트를 돌릴 수 있습니다. execute --class-path out --scan-class-path 는 out 폴더의 클래스를 뒤져 @Test 가 붙은 메서드를 모두 찾아 실행합니다.

java -jar junit-platform-console-standalone-1.11.4.jar \
  execute --class-path out --scan-class-path \
  --details=summary --disable-banner --disable-ansi-colors

--details=summary 는 테스트 트리 대신 통과·실패 개수 요약만 보여 줍니다. --disable-banner·--disable-ansi-colors 는 로그를 CI 콘솔에서 읽기 쉽게 정리합니다.

2.3 종료 코드와 파이프라인 중단

콘솔 런처는 테스트가 하나라도 실패하면 종료 코드 1 을 돌려줍니다. 성공하면 0 입니다. 파이프라인 도구는 이 숫자만 보고 다음 스텝을 실행할지 멈출지 정합니다.

셸에서는 if 명령; then ... else ...; fi 로 종료 코드를 바로 분기할 수 있습니다. set -e 를 쓰면 아예 실패한 명령에서 스크립트 전체가 멈춥니다.

if java -jar console.jar execute --class-path out --scan-class-path; then
  echo "다음 단계로 진행"
else
  echo "여기서 중단"; exit 1
fi

2.4 테스트 리포트

--reports-dir=reports 를 붙이면 JUnit XML 형식 리포트가 폴더에 남습니다. TEST-junit-jupiter.xml 같은 파일에 테스트 개수·실패 개수·소요 시간이 들어 있고, CI 도구는 이 XML 을 읽어 "몇 개 중 몇 개 통과" 화면을 그립니다.

2.5 커버리지란

커버리지는 테스트가 코드의 몇 퍼센트를 실행했는지 나타내는 지표입니다. 라인(statement) 커버리지는 실행된 줄 비율, 분기(branch) 커버리지는 if·switch 갈래가 모두 실행됐는지를 봅니다. 숫자가 높다고 품질이 좋은 것은 아닙니다.

2.6 JaCoCo 소개

JaCoCo 는 Java 커버리지 측정 도구로, Gradle·Maven 플러그인으로 붙여 빌드 중 커버리지를 자동 계산합니다. 이 레슨은 Gradle 이 없어 실행하지 않고 개념만 소개합니다.

2.7 정적 검사란

정적 검사는 코드를 실행하지 않고 소스만 읽어 문제를 찾습니다. 컴파일러의 경고(-Xlint), 스타일 검사(Checkstyle), 버그 패턴 검사(SpotBugs) 가 대표적입니다. 테스트보다 먼저 끝나고, 테스트로는 못 잡는 문제(사용하지 않는 변수, 원시 타입 사용)를 잡습니다.

2.8 javac -Xlint 와 -Werror

-Xlint:all 은 컴파일러가 감지하는 잠재 문제를 경고로 보여 줍니다. 기본은 경고만 출력하고 컴파일은 성공(종료 코드 0)합니다.

-Werror 를 더하면 경고를 에러로 승격해 컴파일 자체가 실패(종료 코드 1)합니다. 파이프라인에서 정적 검사를 강제하는 가장 간단한 방법입니다.

javac -Xlint:all -Werror -d out *.java   # 경고 0개가 아니면 실패

2.9 Checkstyle 소개

Checkstyle 은 들여쓰기·네이밍·임포트 순서 같은 스타일 규칙을 검사하는 도구입니다. checkstyle.xml 에 규칙을 정의하고 Gradle·Maven 플러그인이나 단독 jar 로 실행합니다.

2.10 SpotBugs 소개

SpotBugs 는 컴파일된 바이트코드를 분석해 null 역참조, 자원 누수 같은 버그 패턴을 찾습니다. Checkstyle 이 스타일을 본다면 SpotBugs 는 실제 버그 가능성을 봅니다. 두 도구 모두 이 레슨에서는 실행하지 않고 개념만 소개합니다.

2.11 PR 상태 검사와 브랜치 보호

GitHub 의 Checks 탭은 워크플로 잡의 성공·실패(✔ build-and-test 성공, 42초)를 PR 화면에 보여 줍니다. 브랜치 보호 규칙에서 "필수 상태 검사" 로 지정하면 그 잡이 통과하기 전에는 병합 버튼이 막힙니다. 테스트 잡과 정적 검사 잡을 각각 필수로 지정하면, 사람이 확인하지 않아도 게이트가 강제됩니다.

2.12 품질 게이트 기준 정하기

품질 게이트는 "무엇을 통과 기준으로 삼을지" 를 팀이 미리 정하는 것입니다. 기준이 없으면 사람마다 판단이 달라 병합이 늦어지거나 기준 없이 통과됩니다.

기준은 프로젝트 성숙도에 맞춰 점진적으로 올립니다.