본문 바로가기

전체 글

 (197)
CI 과정에서 jacoco를 활용한 테스트 커버리지 확인하기 안녕하세요 브로콜리입니다. 프로젝트를 진행하며, CI 스크립트를 맡게 되었습니다. CI 과정에서는 작성한 테스트가 모두 통과하는지 검증해 품질이 보장된 코드가 merge되도록 하였습니다. 그러나, 단순히 테스트의 결과를 검증하는 것은 테스트 결과를 보장할 뿐입니다. 오히려, 코드가 통합되는 과정에서는 다음과 같은 질문이 중요할 수 있습니다.- 내가 작성한 코드를 검증할만한 테스트를 작성하였는가?- 팀의 전반적인 테스트 커버리지는 어느정도 되는가? 그리고 이렇게 테스트에 대한 커버리지 컨벤션을 확인할 수 있도록 도와주는 것이 바로 jacoco 라이브러리입니다. 오늘은 CI 과정에서 테스트 커버리지를 검증하기 위해 사용했던 jacoco의 설정부터 CI 스크립트에 적용한 과정까지를 기록으로 남겨두고자 합니다...
JsonDeserializer 커스텀으로 외부 API 에러 핸들링하기 Situation : 에러에도 200을 응답하는 외부 API 지각 방지 서비스 오디에서는 A지점에서 B지점까지의 대중교통 소요시간을 측정하기 위해 ODsay API를 활용하였습니다. 외부 API를 활용하면서 외부 API에서 에러를 반환하는 상황에 대한 핸들링도 자연스레 신경을 써야했습니다. 처음에는 자연스레 ResponseErrorHandler를 만들어서 해결하려 했습니다.  밸덩 글에 수록된 ResponseErrorHandler의 예시를 보겠습니다.@Componentpublic class RestTemplateResponseErrorHandler implements ResponseErrorHandler { //에러인지 판단 @Override public boolean hasError(C..
MapStruct로 Domain - Dto 쉽게 매핑하기 안녕하세요 브로콜리입니다. 최근 가까운 사람이 회사 면접을 보면서 Dto, Entity, Domain 간의 객체 매핑 과정에서 MapStruct를 사용해보는 것은 어떻겠냐는 조언을 들었습니다. 여기서 MapStruct라는 키워드를 알게되었고, Domain to Dto 나 Dto to Domain은 개발자에게 참으로 지루한 작업 중 하나이므로 손쉽게 매핑이 가능한 라이브러리가 있다면 한번 알아보고 쉽다는 욕심이 생겼습니다. 이로써 오늘은 MapStruct의 공식문서를 기반으로 실습 코드를 작성하며 학습한 내용을 정리해보려 합니다. MapStruct란?- 객체간 매핑을 손쉽게 도와주는 라이브러리- AnnotationProcessor를 통해 build 타임에 MapperImpl을 getter/setter를 기..
[디베이트 타이머 - 1차 스프린트] 코드 & Git 컨벤션 정하기 이 글은 지난 1차 OT 이후 글 이후의 과정을 담았습니다. 지난 1차 OT에서 각 파트의 프로젝트 요구사항으로 지정했던 것은 코드 컨벤션과 Git 전략에 대한 서술이었습니다. 코드 컨벤션 : 코드 작성 시 팀원끼리 지켜야할 합의된 규칙을 의미합니다.Git 브랜칭 전략 : 브랜치 생성 / 삭제 / 병합에 대한 팀원간의 합의된 규칙을 의미합니다. 이번주 진행사항은  파트끼리 합의한 하나의 규칙을 선정하는 것이었습니다.따라서, 1차적으로 제가 진행했던 프로젝트 `오디`의 백엔드 컨벤션을 기반으로 각 팀원이 추가하고픈 내용 / 삭제하고픈 내용을 자율적으로 적어와 회의가 진행되도록 하였습니다. 그럼 컨벤션 회의에서는 어떤 내용들이 오고갔을까요? 코드 컨벤션백엔드 코드 컨벤션은 크게 3가지로 나누어졌습니다.1) ..
FCM 알림 비동기 + 이벤트 리스닝으로 리팩터링 하기 - 2편(테스트) 안녕하세요 브로콜리입니다. 지난 글에서는 동기화되어 있던 FCM 알림 로직을 비동기 + 이벤트 리스닝을 방식으로 리팩터링한 과정에 대해 소개해드렸습니다. 그 과정에서 1) 알림 로직과 비즈니스 로직간의 결합도 감소 2) latency 성능 개선 이라는 이점을 얻을 수 있었습니다. 그러나, 모든 구현의 완성은 테스트인만큼 비동기 + 이벤트 리스닝 방식을 어떻게 테스트할지 고민이 생겼습니다.Situation : 비동기 + 이벤트 리스닝 방식을 테스트하자! 다시한번 상황을 짚어보겠습니다. 비동기 + 이벤트 리스닝 방식으로 개선된 알림 서비스는 다음과 같은 모습입니다.1) 상위 모듈은 fcmEventPublisher를 통해 이벤트를 발행합니다.2) 발행된 이벤트는 fcmEventListener를 통해 수신합니다..
[디베이트 타이머 - 1차 스프린트] 팀 빌딩과 프로젝트 OT 우아한테크코스 6기를 백엔드를 수료함과 동시에 정말 많은 미련이 남은 활동은 역시나 프로젝트였습니다. 그 아쉬움을 구체화해보자면 다음과 같습니다.- 명확한 문제정의를 통해 그것을 해결하는 서비스를 만들고 싶다.- 실사용자가 있었으면 좋겠다. (== 사용자를 가정한 리팩터링을 하고 싶지 않다)- 서비스의 점진적 성장을 사용자와 함께 하고 싶다 인생 어차피 한번 사는거... 할 생각이 있으면 해야죠!! 실력은 부족하더라도 들이박아보고 싶었습니다.그래서 직접 아이디어를 만들고 프로젝트를 리딩하기로 결정했습니다. 1. 나는 어떤 문제를 해결하고 싶은가 : 아이디어 구체화 이에 레벨4 종료시기에 맞추어 제가 활동했던 도메인들에서 만들고 싶었던 서비스 아이디어를 구체화하기 시작했습니다. 여러가지 도메인이 있었지만 ..
FCM 알림 비동기 + 이벤트 리스닝으로 리팩터링 하기 - 1편 Situation : 알림 로직이 비즈니스 로직과 강결합 & 동기 코드로 좋지 않은 성능 친구의 지각을 방지해주는 프로젝트 `오디`는 사용자에게 다양한 알림을 보내줍니다. 알림의 종류는 다음과 같습니다.타입보내는 시점설명입장 알림약속방 참여 시기친구가 약속방에 참여했음을 알립니다.출발 알림약속에 지각하지 않을 출발 시각본인 혹은 친구가 지각하지 않으려면 지금 출발해야 함을 알립니다.위치 정보 확인 가능 알림실시간 친구 위치 확인 가능 시점현 시각 이후로 친구들의 실시간 위치를 확인 가능함을 알립니다.재촉 알림내가 지각 위기일 때 && 친구가 나를 재촉했을 때친구에게 재촉 알림을 발송합니다. == 콕 찌르기 그러나, 알림에 대한 도메인이 커지면서 몇 가지 문제라 생각되는 지점들이 보였습니다.  문제1. 알..
인수 테스트로 사용자 유즈 케이스 파악하기 Situation : 2차 UT에서 발생한 예상치 못한 에러 프로젝트 오디에서는 10.10 - 10.24일 간 20명의 패널을 대상으로 사용자 유저 경험을 수집했습니다. 이 중 가장 많은 피드백을 받았던 것 중 하나가 바로 약속방을 나가는 기능을 만들어달라는 것이었습니다. 이에 2차 UT 이전까지 약속방을 나갈 수 있는 기능을 개발하기로 결정하였고, 구현부터 테스트 코드까지 코드 리뷰를 통해 검증된 코드를 merge 하였습니다. 그러나 2차 UT 당일 날, UT 패널인 비토로부터 약속에서 나간 이후 동일 약속에 참여가 되지 않는다는 문자가 왔습니다. 이에 로그를 살펴보니 약속 참여원인 Mate에 회원 아이디(member_id)와 약속 아이디(meeting_id)를 기준으로 구성한 복합 unique 조건에..

티스토리툴바