🧨

코드 커버리지 툴 적용기(feat. JaCoCo)

생성일

2022/10/13

태그

test

infra

목차

배경

저희는 프로젝트의 비즈니스 로직 개발에 몰두하면서 테스트에 다소 소홀했지만 크게 문제로 인식하지는 않았습니다. 그러다가 개발 서버에 배포한 비즈니스 로직 중 미처 테스트 코드를 작성하지 못한 부분에서 예외가 발생하는 상황을 마주했습니다. 그래서 팀 내부 회의를 거쳐, 테스트에 관심을 가지고 테스트 케이스를 늘리기로 결정했습니다. 하지만 테스트 케이스를 늘려도 기존에 있던 로직들을 모두 커버하지 못해 유사한 예외가 발생하거나, 새로운 로직에 대해 테스트 커버를 했는지 확신할 수 없는 상황이었습니다.

이에 테스트 코드 커버리지를 정량적으로 측정하고 문서화를 할 수 있는 툴을 도입하기로 결정하였습니다.

JaCoCo 채택 이유

JaCoCo 적용 이전까지는 인텔리제이의 Run with Coverage 기능을 사용하였습니다. 해당 기능은 쉽게 접근이 가능하다는 장점이 있었지만, 문서화가 어렵고 측정 기준을 세부화하기 힘들어 JaCoCo 도입을 결정하였습니다.

JaCoCo 를 채택한 이유는 다음과 같습니다.

문서화가 쉽다.

•

설정을 통해 측정된 결과를 html, xml 등의 파일 형태로 만들어낼 수 있습니다.

더 자세하다.

•

세부적인 설정으로 측정 단위, 기준 등을 세부적으로 설정할 수 있습니다.

테스트 커버를 강제할 수 있다.

•

측정된 결과가 설정한 단위 및 기준에 대한 규칙을 통과하지 못하면 build 에 실패하게 됩니다.

기본 설정

앞으로 기술될 gradle 은 Groovy DSL 을 기반으로 합니다. 기본적인 설정은 다음과 같습니다.

plugins {
	id 'jacoco'
}

jacoco {
	toolVersion = '0.8.7'
}

jacocoTestReport {
  reports {
    html.enabled true
    xml.enabled true
    csv.enabled false
  }
}

jacocoTestCoverageVerification {
  violationRules {
    rule {
      element = 'CLASS'

      limit {
        counter = 'BRANCH'
        value = 'COVEREDRATIO'
        minimum = 0.90
      }
    }
  }
}
Groovy
복사

•

plugin

◦

jacoco 플러그인을 추가합니다.

◦

플러그인은 이후에 기술할 task 의 묶음입니다. 라이브러리와 성격이 비슷하고, 라이브러리가 코드에서 사용할 객체와 메서드의 묶음이라면, plugin 은 gradle 에서 사용할 메서드의 묶음이라고 생각하면 됩니다. 

•

jacoco

◦

jacoco plugin 에 대한 설정을 할 수 있습니다.

◦

toolVersion 이외에도 reportsDirectory(생성된 파일 디렉토리)등을 설정할 수 있으며 기본값은 $buildDir/reports/jacoco 입니다.

•

jacocoTestReport, jacocoTestCoverageVerification

◦

jacoco plugin 에 포함되어있는 task 입니다. 이후에 이 task 를 오버라이딩하여 사용할 예정입니다.

기본 task

앞서 언급했듯이, jacoco plugin 에는 jacocoTestReport 와 jacocoTestCoverageVerification 두 가지 task 가 있습니다.

•

jacocoTestReport

◦

바이너리로 된 커버리지 결과를 여러 파일 형태로 저장합니다. html 은 결과 분석용, xml과 csv는 외부 분석 도구와의 연동을 위해 만듭니다.

•

jacocoTestCoverageVerification

◦

원하는 커버리지 기준(룰)을 세울 수 있습니다. 기준을 충족하지 못한다면 build 가 실패하게 됩니다.

./gradlew test jacocoTestReport jacocoTestCoverageVerification
Bash
복사

위의 명령어를 실행하면 기본 directory 인 /build/reports/jacoco/test/html/index.html 에 파일이 생성된 것을 확인할 수 있습니다.

규칙을 통과하지 못하면 build 에 실패합니다.

두 task 를 한번에!

task testCoverage(type: Test) {
  group 'verification'
  description 'Runs the unit tests with coverage'

  dependsOn(':test',
            ':jacocoTestReport',
            ':jacocoTestCoverageVerification')

  tasks['jacocoTestReport'].mustRunAfter(tasks['test'])
  tasks['jacocoTestCoverageVerification'].mustRunAfter(tasks['jacocoTestReport'])
}
Groovy
복사

testCoverage 라는 task 를 만들고 해당 task 에서 위의 두 task 를 묶을 수 있습니다.

•

group

◦

gradle 의 task 는 여러가지 그룹(Application, Build, Build Setup, Documentation, Verification 등)으로 나뉩니다.

◦

이 그룹들의 task 들이 유기적으로 결합하고 실행되어 빌드 또는 스프링부트 실행을 할 수 있습니다. terminal 에서 아래의 명령어를 입력하면 각각의 task 에 대한 설명을 확인할 수 있습니다.

./gradlew tasks 
Bash
복사

•

mustRunAfter

◦

mustRunAfter 으로 태스크 순서를 지정해줄 수 있습니다.

◦

mustRunAfter 는 dependsOn 보다 후순위입니다. 이외의 메서드들은 빌드 스크립트 기초를 참고해주세요!

이 설정으로 ./gradlew testCoverage 명령어를 실행하면 ./gradlew test jacocoTestReport jacocoTestCoverageVerification 명령어와 같은 실행을 할 수 있습니다.

세부 설정

jacocoTestCoverageVerification 태스크에서 커버리지 기준을 자세하게 설정할 수 있습니다.

다음은 저희 모락 팀이 회의를 통해 정의한 룰입니다.

tasks.named('jacocoTestCoverageVerification') {
    violationRules {
        rule {
            element = 'CLASS'

            limit {
                counter = 'BRANCH'
                value = 'COVEREDRATIO'
                minimum = 0.80
            }

            limit {
                counter = 'LINE'
                value = 'COVEREDRATIO'
                minimum = 0.70
            }

            limit {
                counter = 'METHOD'
                value = 'COVEREDRATIO'
                minimum = 0.60
            }

            excludes = [
                    '**.*Formatter*',
                    '**.*BaseEntity*',
                    '**.*GithubOAuthClient*',
                    '**.*MorakBackApplication*',
                    '**.*Interceptor*',
                    '**.*Extractor*',
                    '**.RestSlackClient',
                    '**.*Config'
            ]
        }

        rule {
            element = 'METHOD'

            limit {
                counter = 'LINE'
                value = 'TOTALCOUNT'
                maximum = 200
            }
        }
    }
}
Groovy
복사

violationRules 속성에서 rule 을 정의할 수 있으며, 여러 개의 rule 을 정의할 수 있습니다.

•

element

◦

커버리지를 체크할 기준을 설정합니다.

◦

가능한 값으로는 BUNDLE, PACKAGE, CLASS, GROUP, SOURCEFILE, METHOD 가 있으며 기본 값은 BUNDLE 입니다.

•

counter

◦

커버리지 측정의 최소 단위입니다.

◦

가능한 값으로는 INSTRUCTION, LINE, BRANCH, COMPLEXITY, METHOD, CLASS 가 있으며 기본 값은 INSTRUCTION 입니다.

•

value

◦

커버리지를 측정할 단위입니다.

◦

가능한 값으로는 TOTALCOUNT, MISSEDCOUNT, COVEREDCOUNT, MISSEDRATIO, COVEREDRATIO 가 있으며 기본 값은 COVEREDRATIO 입니다.

위의 3개를 조합해서 사용할 수 있습니다.

ex)

PACKAGE, METHOD, COVEREDRATIO → 패키지의 메서드 커버비율

METHOD, BRANCH, COVEREDRATIO → 메서드의 분기 커버비율

CLASS, LINE, TOTALCOUNT → 클래스의 라인 총 갯수

•

includes

◦

각각의 rule 에서 지정된 element 를 기준으로, 포함할 element 를 지정할 수 있습니다.

◦

기본 값은 모든 element 입니다([*]).

•

excludes

◦

각각의 rule 에서 지정된 element 를 기준으로, 제외할 element 를 지정할 수 있습니다.

◦

기본 값은 빈 list 입니다.

◦

ant 스타일로 값을 지정할 수 있습니다.

메서드 제외하기

위의 rule 을 활용하여 클래스 내부에 포함된 equals 와 같은 메서드를 측정에서 제외하려고 했는데 문제가 발생했습니다. rule 에서 exclude 할 수 있는 항목은 element 에서 정의된 CLASS 입니다. 그래서 해당 rule 에서 exclude 로는 클래스의 메서드를 exclude 로 제외할 수 없었습니다. 즉 element 가 클래스이면 클래스만 제외할 수 있고, element 가 메서드여야 메서드를 제외할 수 있습니다.

저희 프로젝트에는 서비스 로직 상 equals 와 hashCode 를 재정의한 로직이 있는데, 굳이 테스트할 필요가 없어서 테스트 케이스에 추가하지 않았습니다. 하지만 해당 메서드를 테스트하지 않으면 지정한 rule 의 BRANCH 와 METHOD 에서 걸려, 빌드에 실패하게 되었습니다. 테스트 커버리지를 위해 해당 메서드를 테스트하여 불필요한 테스트 케이스를 추가하기보다는, 해당 메서드를 측정에서 제외하는 방법을 찾아보았습니다. 저희가 겪은 문제를 많은 개발자들이 요구했는지, JaCoCo 0.8.2 부터는

'Generated' 라는 단어가 이름에 포함 

RetentionPolicy 가 'CLASS' 또는 'Runtime' 

을 충족하는 어노테이션이 붙어있으면 해당 Target 은 JaCoCo 측정에서 제외할 수 있다고 합니다.

이에 따라 위의 기준을 충족하는 어노테이션을 만들고, 테스트가 불필요한 메서드에 만든 어노테이션을 달아주었습니다.

@Documented
@Retention(RUNTIME)
@Target({TYPE, METHOD})
public @interface Generated {
}
Java
복사

@Override
@Generated
public boolean equals(Object o) {
        // ...
}
Java
복사

단점으로는 서비스 코드에 테스트 코드 로직이 들어간다는 점이었습니다. 하지만 이러한 단점보다는 테스트 케이스의 순도를 높이는 것이 더 적합하다고 판단하여 위의 어노테이션 방식을 사용하기로 결정하였습니다.

lombok 관련 제외하기

저희 프로젝트에서는 재정의한 equals, hashcode 메서드 뿐만 아니라 NoArgsConstructor, Getter 등의 lombok 어노테이션도 이용하고 있습니다. 이에 따라 해당 lombok 관련 메서드들도 테스트 커버리지에 측정되어 빌드에 실패하는 경우가 생겼습니다. 이에 따라 lombok 과 관련된 문제도 측정에서 제외하기로 결정하였습니다.

lombok.addLombokGeneratedAnnotation = true
Plain Text
복사

프로젝트 루트 디렉토리 하위에 lombok.config 파일을 project 의 root path 에 생성하고 위와 같은 설정을 해주었습니다. 이 설정은 모든 lombok 으로 생성된 메서드에 대해 ‘Generated’ 어노테이션을 붙인다는 설정입니다.

설정 분석

위와 같이 테스트가 불필요한 메서드와 lombok 관련 메서드를 제외하는 것이 가능한 이유는 lombok 의 메서드 생성 시점과, JaCoCo 의 코드 커버리지 측정 방식에 있습니다.

lombok 메서드 생성 시점

lombok 의 메서드는 complie 시에 생성이 됩니다(annotation processing). 이에 따라 커스텀한 어노테이션인 @Generated 가 붙은 메서드나 lombok 메서드는 compile 된 이후 생성된 class 파일의 메서드에@Generated 가 붙어있습니다.

JaCoCo 측정 방식

JaCoCo 는 Java Agent 로 실행이 됩니다. 이에 따라 바이트 코드를 직접 관리할 수 있으며, 테스트 실행 중에 각각의 코드를 보면서 어떤 코드 라인이 수행되었는지 확인하면서 커버 비율을 측정합니다. 이러한 방식 덕분에 class 파일에 @Generated 가 붙은 메서드는 측정에서 제외할 수 있는 것입니다.

분석 결과

PR 시 SonarQube 로 코드 정적 분석과 함께 JaCoCo 로 측정된 결과에 대해서도 분석하여 분석 결과를 PR 덧글로 알려줄 수 있도록 하였습니다. 앞서 설정한 4개의 규칙을 통과하지 못하면 build 에 실패하게 되고, SonarQube 에서도 전체적인 통과 기준을 80% 로 잡아 전체 코드에 대해서도 테스트 커버리지에 대해 측정할 수 있도록 하였습니다.

참고

https://techblog.woowahan.com/2661/

https://as-you-say.tistory.com/142#h2-7

https://www.baeldung.com/jacoco