[Spring & Github] Pull Request를 할 때 마다 테스트 커버리지를 확인하자 (feat. Jacoco)

안녕하세요. dev_writer입니다.

 

이번 시간에는 코드 커버리지 도구 중 하나인 Jacoco를 적용한 과정에 대해 알려드리겠습니다.

 

Jacoco

Jacoco는 자바 코드 커버리지를 측정하고 리포팅할 수 있는 오픈 소스 툴킷입니다. (위키백과) 애초에 Jacoco라는 단어 자체가 Java code coverage tools라는 단어를 내포하고 있습니다.

 

코드 커버리지 (code coverage)
코드 커버리지는 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표입니다. 소프트웨어 테스트를 진행했을 때 코드 자체가 얼마나 실행되었는지를 뜻합니다. - 위키백과

 

일반적으로 테스트 코드를 꼼꼼하게 작성할수록 예외 케이스들을 잘 탐지할 수 있으며, 그렇기에 소프트웨어의 품질을 높이기 위해서는 테스트 커버리지가 너무 낮지 않아야 할 것입니다.

 

그러면 Jacoco를 적용하는 방법에 대해 본격적으로 알아보겠습니다.

 

1단계: build.gradle에 jacoco 적용

프로젝트의 build.gradle에 jacoco를 적용합니다.

// 1단계
plugins {
    ...
    id 'jacoco'
}

// 2단계
test {
    ...
    finalizedBy jacocoTestReport
}

// 3단계
jacoco {
    toolVersion = "0.8.12"
}

// 4단계
jacocoTestReport {
    dependsOn test
    reports {
        xml.required.set(true)
    }
}

• 1단계: jacoco 플러그인을 설치합니다.
• 2단계: 테스트가 완료된 후 jacocoTestReport가 실행되도록 합니다.
• 3단계: jacoco의 버전을 설정합니다.
• 4단계: jacocoTestReport가 실행되기 전에 test가 실행되도록 설정하고, 코드 커버리지 보고서를 XML 형식으로 생성하도록 설정합니다. (XML 형식으로 생성하면, Pull Request에서 커버리지 결과를 표로 보기 용이합니다.)

 

마주쳤던 문제 1: jacoco 버전을 확인하자

기존에는 여러 블로그 글들을 참고하여, jacoco 버전을 0.8.8로 설정했었습니다. 그 결과, 아래처럼 테스트 중 오류가 발생했었음을 볼 수 있었습니다.

테스트 중 발생한 IllegalClassFormatException

 

이에 대해 스택오버플로우를 참고하니, 자바 버전이 jacoco와 맞지 않을 때 이런 일이 발생할 수 있다는 사실을 알게 되었습니다.

 

실제로 jacoco의 깃허브에 직접 가셔서 태그를 보시면, 버전이 꾸준히 올라오고 버전에 따라 지원되는 자바 버전 또한 다름을 볼 수 있습니다.

프로젝트에서 사용되는 Java 21은 jacoco 0.8.11 부터 가능합니다.

 

따라서 24년 10월 기준 가장 마지막으로 올라온 버전인 0.8.12로 업그레이드하니, 문제가 해결될 수 있었습니다.

 

2단계: github actions 스크립트 작성

jacoco 커버리지 지표를 Pull Request에 남기기 위해 github actions 스크립트를 작성합니다.

name: Jacoco Test Coverage Check

// 1단계
on:
  pull_request:
    types: [opened, synchronize, reopened]

// 2단계
permissions: write-all

// 3단계
jobs:
  test:
    runs-on: ubuntu-latest
	
    steps:
      // 3-1단계
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

	// 3-2단계
      - name: Set up JDK 21
        uses: actions/setup-java@v3
        with:
          distribution: 'adopt'
          java-version: '21'

      // 3-3단계
      - name: Create and inject jasypt secret into application-secret.properties
        run: |
          touch ./src/main/resources/application-secret.properties
          echo "ENCRYPT_KEY=${{ secrets.ENCRYPT_KEY }}" > ./src/main/resources/application-secret.properties
          cat ./src/main/resources/application-secret.properties

      // 3-4단계
      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      // 3-5단계
      - name: Test with Gradle
        run: |
          export ENCRYPT_KEY=${{ secrets.ENCRYPT_KEY }}
          ./gradlew --info test

      // 3-6단계
      - name: Test Coverage Report
        id: jacoco
        uses: madrapps/jacoco-report@v1.7.1
        with:
          title: Test Coverage Report
          paths: ${{ github.workspace }}/build/reports/jacoco/test/jacocoTestReport.xml
          token: ${{ secrets.GITHUB_TOKEN }}
          min-coverage-overall: 30
          min-coverage-changed-files: 50

• 1단계: Pull Request가 열리거나, 업데이트되거나, 다시 열릴 때마다 워크플로우가 실행되도록 합니다.
• 2단계: 모든 범위에 대해 쓰기 권한을 부여합니다. Pull Request의 코멘트에 쓰기 위해 필요합니다.
• 3-1단계: actions/checkout 액션을 사용하여 현재 리포지터리의 코드를 체크하고, fetch-depth: 0을 설정하여 모든 커밋 기록을 가져옵니다.
• 3-2단계: JDK를 설정합니다.
• 3-3단계: Jasypt 키를 ENCRYPT_KEY로 관리하고 있었기 때문에 이를 주입해 주는 단계입니다.
• 3-4단계: gradlew 실행 권한을 부여합니다.
• 3-5단계: ENCRYPT_KEY를 주입한 뒤 테스트를 실행합니다. (info 플래그는 실행 정보 출력을 제공합니다.)
• 3-6단계: Jacoco 테스트 커버리지 보고서를 생성하는 핵심 단계입니다. github.workspace와 secrets.GITHUB_TOKEN은 깃허브 액션에서 자동으로 제공해 줍니다. 또한, 전체 파일의 최소 커버리지 (min-coverage-overall)와 변경된 파일의 최소 커버리지 (min-coverage-changed-files)를 설정할 수도 있습니다. (두 개 모두 기본값은 80%입니다.)
  • jacocoTestReport에서 path를 별도로 지정할 수 있으며, 별도로 지정하지 않았다면 위의 경로를 사용하면 됩니다.
  • uses의 버전은 여기에서 확인하실 수 있습니다.

 

다음으로는 깃허브 리포지터리에서 Settings > Actions > General > Workflow permissions에 들어가 Read and write permissions를 체크해줘야 합니다.

Github Workflow permissions

 

이후 Pull Request가 실행되면, 아래와 같이 테스트 커버리지를 확인할 수 있습니다.

워크플로우 실행 후 확인할 수 있는 테스트 커버리지

 

마주쳤던 문제 2: 낮은 테스트 커버리지

위의 사진처럼, 테스트 커버리지가 너무 낮게 나왔습니다.

 

실제 로컬에서 테스트 커버리지를 확인해 보면, 못해도 75% 근처는 나와야 했습니다.

로컬에서 확인한 테스트 커버리지

 

그런데 왜 이렇게 테스트 커버리지가 낮았을까요?

 

테스트를 한 후 제공된 문서를 보니, Querydsl과 관련된 코드도 테스트에 포함시키고 있었음을 볼 수 있었습니다.

build/reports/jacoco/test/html에서 확인하실 수 있습니다.

 

Q클래스에 대한 파일들도 Jacoco가 수집하다 보니, 정확한 테스트 커버리지가 측정이 안 된 것이었습니다.

 

따라서 Q클래스를 제거하기 위해 jacocoTestReport를 아래처럼 수정했습니다.

jacocoTestReport {
    dependsOn test
    reports {
        xml.required.set(true)
    }
    afterEvaluate {
        classDirectories.setFrom(
                files(classDirectories.files.collect {
                    fileTree(dir: it, exclude: [
                            '**/Q*.class',
                            '**/com/flab/eattofit/EattofitApplication.class'
                    ])
                })
        )
    }
}

 

마지막에 붙은 클래스는 스프링의 메인 애플리케이션을 뜻합니다. 제외하지 않을 경우 Q클래스처럼 테스트 범주에 포함되어 커버리지를 낮추는 요인이 되기 때문에 붙였습니다.

 

lombok.config 작성

마지막으로, lombok이 작성한 메서드 (@Getter, @Setter..)에 대해서도 커버리지를 포함하지 않기 위해서는 프로젝트 루트 단에 lombok.config를 추가하여 아래처럼 작성하면 됩니다.

lombok.addLombokGeneratedAnnotation = true

 

결과

최종적으로 아래처럼 정상적인 테스트 커버리지를 확보할 수 있었습니다.

최종 생성된 Jacoco의 테스트 커버리지

 

Reference

• [Wikipedia] Java code coverage tools
• [위키백과] 코드 커버리지 (code coverage)
• [TestCode] jacoco를 사용하여 test coverage report 적용하기
• 스택오버플로우 예외 문서
• Jacoco github
• jacoco, lombok 사용 시 code coverage
• 진행한 프로젝트 Pull Request