최근 구현한 게시판 프로젝트가 있다. 이 프로젝트에서 사용되는 메서드에는 대부분 테스트 코드를 작성했다.
이 테스트 코드가 내 실제 프로덕션 코드를 얼마나 커버했는지 나타내는 코드 커버리지를 수치화하는 기술인 SonarQube를 사용해 얼마나 커버했는지 확인해 보자.
참고로 SonarQube는 코드 커버리지뿐만 아니라 Security Hotspot와 같이 보안적으로 문제가 될 수 있는 부분, 유지보수 측면에서 불리할 수 있는 부분 등의 정적 코드 분석 기능도 보유하고 있다.
SonarQube 설치 및 설정
난 HomeBrew를 사용해 SonarQube를 설치했다.
brew install sonar
brew install sonar-scanner
설치가 완료되었으면 실행한다.
brew services start sonarqube
실행되었으면 http://localhost:9000에 접속한다. (SonarQube 기본 URL)
로그인 화면에 입장하면 아이디와 비밀번호를 입력한다.
참고로 아이디와 비밀번호의 초기값은 둘 다 admin이다.
아이디와 비밀번호를 입력한 후, 접속하면 현재 SonarQube에서 검사 중인 프로젝트 목록이 나온다.
이 화면까지 왔다면 Create Project 버튼을 클릭하여 프로젝트 생성 화면에 들어간다.
그다음은 사용할 프로젝트명, 프로젝트 Key, 브런치 명을 설정한다.
프로젝트 Key는 기억하는 게 좋다. 왜냐하면 이후 Spring 서버와 연동할 때, 필요하기 때문이다.
아래의 화면까지 왔다면 프로젝트 생성은 끝났다. 이제 연동만 하면 된다.
다음은 SonarQube와 프로젝트 연동에 사용할 토큰을 발급받아야 한다.
그러기 위해선 상단의 My Account에 들어간다.
Security으로 온 후, 사용할 토큰 명과 프로젝트를 선택한다.
난 토큰명은 board, 연동할 프로젝트는 직전에 생성한 board를 선택했다.
Generate 버튼을 누르면 sqp_926… 와 같이 토큰이 생성된다. 이것도 Spring 설정에 필요하기 때문에 반드시 기록해둬야 한다.
Spring, SonarQube 연동
다음은 Spring에서 build.gradle을 수정해줘야 한다.
plugins {
...
id "org.sonarqube" version "5.0.0.4638"
id 'jacoco'
}
...
jacoco {
toolVersion = "0.8.8"
}
jacocoTestReport {
reports {
xml.required.set(true) // XML 리포트 활성화
html.required.set(false) // HTML 리포트 비활성화
}
}
test {
finalizedBy jacocoTestReport // 테스트가 완료된 후 jacocoTestReport 태스크를 실행
}
sonarqube {
properties {
property "sonar.projectKey", "이전에 설정한 프로젝트 Key"
property "sonar.host.url", "<http://localhost:9000>"
property "sonar.login", "이전에 발급받은 토큰"
property "sonar.java.coveragePlugin", "jacoco"
property "sonar.coverage.jacoco.xmlReportPaths", "${buildDir}/reports/jacoco/test/jacocoTestReport.xml"
}
}
이렇게 build.gradle에 코드를 추가해 주면 설정은 끝났다.
코드 분석
이제 SonarQube가 수치화하는데 필요한 JaCoCo 리포트를 생성해야 한다.
리포트 생성은 터미널에선 아래의 명령어를 입력하면 된다.
./gradlew test jacocoTestReport
참고로 모든 테스트 코드가 정상적으로 동작해야 리포트가 생성된다!
테스트 리포트가 정상적으로 생성되었다면 아래의 명령어를 통해 분석을 실행할 수 있다.
./gradlew sonarqube
이젠 SonarQube로 돌아가서 코드 분석 결과를 확인하면 된다.
코드 분석 결과는 좀 처참했다..
테스트 코드를 쓴다고 썼는데 커버리지가 겨우 70%다..
커버리지 분석 결과를 확인하고 싶으면 Coverage 아래의 퍼센트를 클릭하면 된다.
내부 내용을 확인한 결과 주로../global/.. 와 같이 설정에 해당하는 클래스의 커버리지가 7.7%, 11.1%, … 등등 현저하게 낮았다.
뭐 난 나중에 저 코드들의 테스트 코드를 작성할 것이지만, 코드 커버리지를 높이기 위해서 저 코드들을 삭제할 순 없다.
이러한 상황을 대비해 SonarQube에선 저런 설정 관련 클래스나 DTO 같이 굳이 테스트할 필요가 없다고 생각되는 클래스는 분석에서 제외할 수 있다.
Project명 → Project Settings → General Settings → Analysis Scope → Code Coverage Exclusions
이 경로대로 들어간 후 제외하고 싶은 클래스를 추가하면 된다.
난 DTO 클래스와, 설정파일이 주로 담겨있는 global 패키지 하위 클래스들을 추가해 줬다.
이렇게 분석에서 제외할 클래스를 추가한 뒤 Coverage를 확인한 결과 98%까지 올랐다.
이렇게 높을 수밖에 없는 이유는 코드 구현을 TDD로 했기 때문이다.
이뿐만 아니라 Maintainability 결과에선 불필요한 의존성이나 복잡한 코드 구조, 과도한 중복, 비효율적인 알고리즘 등을 분석해 수정이 필요한 코드를 알려준다.
'Spring' 카테고리의 다른 글
[Spring] Spring Security 정리 (0) | 2025.05.01 |
---|---|
[Spring] MySQL, MongoDB 전략 패턴 (0) | 2025.04.23 |
[Spring] Spring Batch를 사용한 대량 데이터 저장 (2) (0) | 2024.12.22 |
[Spring] Spring Batch를 사용한 대량 데이터 저장 (1) (3) | 2024.12.21 |
[Spring] Controller 테스트 코드 (Feat : Spring Security) (1) | 2024.12.19 |