최근에 우테크 블로그를 읽고, 코드의 품질을 관리하기 위해 Jacoco라는 도구를 도입했습니다. Jacoco는 코드 커버리지를 측정하는 도구로, 제가 작성한 테스트가 얼마나 코드를 잘 커버하는지 알려줍니다. 이를 통해 놓친 테스트 케이스를 찾아내고, 더 견고한 코드를 작성할 수 있었죠. 하지만, 실제 업무 중 급박한 상황을 겪으며 '긴급할 때는 코드 커버리지를 잠시 무시하고 버그부터 고쳐야 한다'는 생각이 들었습니다. 그래서 Jacoco 검사를 상황에 따라 선택적으로 실행하도록 설정하는 방법을 모색했습니다. Jacoco 설정 과정과 브랜치 변경 1. 첫 시도 - 우테크 블로그의 기본 설정: test { finalizedBy 'jacocoTestReport' } 설명: 이 설정은 Gradle의 test 태..

JaCoCo 란? JaCoCo는 Java 코드의 커버리지를 체크하는 라이브러리입니다. 여기서 코드의 커버리지란 내 테스트 코드가 내 코드의 몇 퍼센트를 보증하냐!라고 생각하시면 편합니다. 테스트코드를 돌리고 그 커버리지 결과를 눈으로 보기 좋도록 html이나 xml, csv 같은 리포트로 생성합니다. 그리고 테스트 결과가 내가 설정한 커버리지 기준을 만족하는지 확인하는 기능도 있습니다. 최근 이러한 JaCoCo를 활용해 코드의 품질을 높이려는 노력을 하던 와중에 특이한 점을 찾았습니다. 특이점 JaCoCo 를 통해 테스트의 커버리지를 측정하던 와중 테스트 코드를 작성했는데도 커버리지가 카운팅이 되지 않는 부분을 발견했습니다. 다음은 문제의 코드입니다. @Test @DisplayName("updatePo..

최근 코드 품질을 올리고 싶어 IDE에 SonarLint을 설치했더니 다음과 같은 경고를 받게 됐다. 요는 테스트 메서드에서 public 접근 제어자를 없애라라는 경고이다. 필자가 아는 지식은 JUnit 이 실행시에 테스트 메서드를 Reflection API로 뜨기 위해서 public 접근 제어자가 필수라고 알고 있었다. JUnit 5 제작자 왈 public 일 필요는 없지만, private 이면 안된다! 일반적으로 public 제어자는 기술적인 모종의 이유가 아닌 이상 쓰지 말아라 [출처] : https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods 요약하자면 우리 JUnit 5 팀은 "Less is more"..

상황 어제 EC2에 Spring Boot와 MySQL을 실행시키려 하니 다음과 같은 에러가 나왔습니다. 이유는 OOM(Out Of Memery) Killer 가 mysql.service를 죽였다는 것. 사실 이럴만도 한 게 기존에 쓰던 EC2의 스펙이 t4g.nano였습니다. 이 EC2 인스턴스의 스펙은 대략 다음과 같습니다 AWS Gravition Processor(CPU) 2 개와 메모리 500MB짜리입니다. 여기서 주요 문제는 메모리 용량입니다. 현재 지금 돌아가고 있는 EC2의 RSS(실제 사용하는 물리 메모리양)를 보면 mysql 은 396MB, Spring Boot는 222MB 인걸 확인할 수 있습니다. (상황 종료 후의 spring boot, mysql을 확인한 것입니다.) 심지어 mysql..

배경 @Transactional @Scheduled(cron = "0 0 * * * *") public void updatePopularPosts() { // 새로운 상위 10개 게시물 추출 List top10Posts = postRepository.findTop10Posts(); // 기존의 data 삭제 popularPostRepository.deleteAllInBatch(); // 변환 후 새로운 data 삽입 List popularPosts = convertToPopularPost(top10Posts); popularPostRepository.saveAll(popularPosts); } 위 함수에 대한 테스트 코드를 작성해보려 하다 이런 글을 쓰게 되었습니다. 테스트의 목적은 매 정시에 함수가 실..

현재 다음과 같은 작업을 진행 중에 있습니다. 💡 데이터베이스에 1억 건이 있을 때 나의 가련한 API의 성능(반응시간)은 어느 정도 나올까? 현재 조회 쿼리는 인덱스도 뭐도 없고 단순한 형태의 CRUD 의 조회용 쿼리이기 때문에 1억 건에서 데이터를 뽑는 데는 실제로 오래 걸릴 것입니다. // 실제 사용하는 오늘의 코드 @Override public List findAllDTOs(Integer offset, Integer limit) { return queryFactory .select(new QPostDbDTO( post.id, post.title, post.content, post.member.name, post.isDeleted, post.reg_date )) .from(post) .orderBy..