15. jacoco를 통한 테스트 커버리지 체크

코드 커버리지

코드 커버리지는 소프트웨어의 테스트 케이스가 얼마나 충족되었는지를 나타내는 지표 중 하나이다. 테스트를 진행하였을 때 ‘코드 자체가 얼마나 실행되었느냐’는 것이고, 이는 수치를 통해 확인할 수 있다.

 

jacoco

Java code coverage의 약자로 

junit 테스트의 결과를 바탕으로 커버리지를 결과를 리포트 해주는 툴 입니다.

특히 코드정적분석도구인 sonarqube와 연계하여 사용하는 경우가 많습니다.

 

앞선 툴들에 대한 자세한 설명은 다른 포스팅에서 진행할 예정입니다. 이번 글은 제 프로젝트에 적용해볼려고 합니다.

 

1. build.gradle에 jacoco 추가

- plugins에 아래처럼 추가

plugins {
	...
	id 'jacoco'
}

...
}

추가한 뒤 gradle reload를 진행해주면 verification 에 아래 와 같이 추가됩니다.

2. gradle test 진행

- 위 사진의 test를 더블 클릭하셔도 되고 gradle test 명령어로 하셔도 됩니다.

- test 진행이 완료 되면 build > test 폴더 안에 index.html을 발견하실 수 있습니다. 

- 끌어다가 띄우고 크롬을 통해서 열면

- 이런 화면을 확인 하실 수 있습니다. 이건 jacoco가 아니라 그냥 test 결과입니다.

- 이제 jacoco 리포트를 확인해봅시다.

3. jacocoTestReport 실행

- jacocoTestReport를 더블클릭해서 실행해줍니다.

- build > report > jacoco 폴더 안에서 index.html을 확인 하실 수 있습니다. 열어줍니다.

5. 결과 확인

- 원래 전체 결과가 나오는데 생각보다 참혹해서 ㅎㅎㅎ 깨달은 부분만 .... 후후 ..

- 프로젝트 중에 mockito를 이용해서 단위 테스트를 진행하면서 신경을 제일 쓴 service 테스트인대 어디를 안타는 거지 했습니다....

- 내용 확인을 해보니 아래처럼 예외 테스트가 부족했다는 것을 확인 하였습니다. 

- 생각해보니 파일 업로드 등 파일 관련 처리를 s3로 옴기고 나서 테스트 코드를 추가하지 않았다는걸 알게되었습니다.

(추가해야지 .....ㅠㅠㅠㅠ)

 

- 27%? 이게 뭐지 라는 생각으로 확인 해보니 (참혹한 dto 테스트 커버리지 .....) 

- Dto에 롬복을 통해서 @Data를 통해서 setter 생성하고 한번도 안써서 생긴 내용 이었습니다 .ㅎ (@Builder 짱짱맨.ㅎ)

- dto 테스트를 추가하면

import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.*;

class ProjectResponseDtoTest {

    @Test
    void projectResponseDtoTest() {
        ProjectResponseDto projectResponseDto1 = new ProjectResponseDto();
        projectResponseDto1.setProjectId(1L);
        projectResponseDto1.setProjectTitle("이름");
        projectResponseDto1.setProjectContent("내용");
        projectResponseDto1.setProjectPostScript("추신");
        projectResponseDto1.setFileUrl("파일 주소");
        projectResponseDto1.setFileOriginName("파일 이름");
        projectResponseDto1.setProjectLink("프로젝트 링크");
        projectResponseDto1.setLevel(1);
        projectResponseDto1.setMemberId(1L);

        ProjectResponseDto projectResponseDto2 = ProjectResponseDto.builder()
                .projectId(1L)
                .projectTitle("이름")
                .projectContent("내용")
                .projectPostScript("추신")
                .fileUrl("파일 주소")
                .fileOriginName("파일 이름")
                .projectLink("프로젝트 링크")
                .level(1)
                .memberId(1L)
                .build();

        assertAll(
                () -> assertThat(projectResponseDto1).isEqualTo(projectResponseDto2),
                () -> assertThat(projectResponseDto1.toString())
                        .hasToString("ProjectResponseDto(projectId=1, projectTitle=이름, projectContent=내용," +
                                " projectPostScript=추신, fileUrl=파일 주소, fileOriginName=파일 이름," +
                                " projectLink=프로젝트 링크, level=1, memberId=1)")
        );
    }
}

 

- 테스트 커버리지가 올라가긴합니다만

 

- 과연 dto를 테스트하는게 의미가 있는지 위와 같은 코드를 작성하는 게 의미가 있는지 등을 생각하게 되면서 jacoco 설정을 찾아보게 되었습니다.

 

- 저의 경우 dto와 querydsl에 의해 생기는 Q클래스를 제외하도록 특정 디렉토리의 특정 클래스를 제외시키는 방법을 사용하였습니다.( 제가 사용한 방법과 다른 방법 등은 아래 주소에서 확인하실 수 있습니다.)

// build.gradle 에 추가

jacocoTestReport {
	dependsOn test // tests are required to run before generating the report

	afterEvaluate {
		classDirectories.setFrom(files(classDirectories.files.collect {
			fileTree(dir: it, exclude: [
					"com/myintroduce/web/dto/*",
					"**/Q*.class"
			])
		}))
	}
}

 

찾아본 결과 디렉토리, 제외, 최소 테스트 커버리지 % 설정 등 다양한 설정이 가능하다는 것을 알게 되었습니다. 

(차후에 공부해야지 .ㅎ)

 

후기

다른 툴을 적용할 때 후기 같은거 안 적었는데 테스트 코드를 신경 쓴다고 했는데도 불구하고 많이 부족하다는 걸 알게되어서 좋은 경험이었다는 생각이 들어서 적게 되었습니다. 모두 사용을 추천 드립니다 .ㅎ

 

(저는 이제 테스트 코드 짜러)

 

Reference

https://www.baeldung.com/jacoco-report-exclude

https://docs.gradle.org/current/dsl/org.gradle.testing.jacoco.tasks.JacocoReport.html

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