멀티 모듈 구조의 프로젝트를 개발하는 과정에서 Exception에 대해 기존 단일 모듈 프로젝트의 구조와는 다르게 설계해야겠다는 생각이 들었습니다. 그 과정에서 고민했던 내용을 기술합니다. 멀티모듈에서 Exception 처리를 고민하는 이유 모듈간 의존성 규칙 문제 상황 예시 : web모듈에서 결국 jpa의존성이 필요하게 되는 상황 web, batch, store-jpa, resclient 등으로 여러 모듈로 나누면 각 모듈은 자신이 꼭 필요한 의존성만을 포함해야 합니다. 하지만 가끔 기존 관성에 의해서 아래와 같이 web 모듈에서 바로store-jpa 모듈의 참조가 이루어져야 하는 경우가 있습니다 @RequiredArgsConstructor public class WebModuleSomeService ..
외부 API 연동 로직 개발하기 로직을 작성하다 보면 외부 API와의 연동은 피할 수 없게 되었습니다. 피할 수 없게 되었지만 테스트 코드를 짜기에는 아직도 까다로운 것도 사실입니다. 아직 Request날려볼 API 실체도 없다고....? 아직 연동 api의 실체도 없고 서로 약속한 문서만 있을 경우는 테스트 코드는 고수하고 로직 작성 조차도 더욱 까다로워집니다. (벌써 어지러워집니다...)😵💫😵💫😵💫😵💫 그래, 연동할 API 없다고 개발 못하는건 아니니까 연동할 API의 실체가 없다고 개발못하는건 아닙니다. 약속된 문서가 있기때문에 문서 기준으로 가능한 로직을 작성해 봅니다 실체가 없는 외부 API 연동 로직 먼저 개발하기 연동 API 명세 1. GET URL : http://user-api.c..
Memory db를 이용한 Repository Test Repository layer의 테스트를 위해서 내장 Memory DB를 많이 사용합니다. Memory DB 를 사용하는 방법도 천차만별일텐데 크게는 2가지 정도라 생각됩니다. @SpringBootTest+ Memory DB 연결 @DataJpaTest 두 방법의 차이점과 [Junit & JPA의 영속성 컨텍스트]로 인한 여러 가지 현상에 대해 정확히 알기 위해 글을 작성합니다. 두 가지 방법의 쿼리 로그가 다른데? 위 2가지 방법 중 어느것을 선택해서 Repository Layer 테스트를 진행할까 고민하던 중 제 예상과는 다른 쿼리 로그가 찍히는 것을 확인했습니다. 테스트한 코드는 아래 2가지입니다. 예제 코드 // Member.java @Get..
IntelliJ에서 자주 보이는 메세지...? Lambda can be replaced with method reference Anonymous new Consumer() can be replaced with lambda Anonymous new Consumer() can be replaced with method reference IntelliJ를 이용해서 개발하다보면 위와같은 메세지와 함께 여러 Refacotring 들이 생깁니다. 그리고 어떤 옵션을 선택하는 순간 마법처럼 IntelliJ가 코드를 간결하게 만들어줍니다. IntelliJ의 유혹(?) 이런 IntelliJ의 유혹(?)에 견디지 못해 막 실행하다보면 왜 이렇게 코드가 변했는지 알지 못하고 해당 로직에서 문제가 발생했을 때 트러블 슈팅에서..
Intellij가 알아서 고쳐주던 아래 에러에 대해서 좀 더 깊숙히 알고자 정리하는 글입니다. Variable used in lambda expression should be final or effectively final 에러에 대한 결론부터 람다 실행시에 실행되던 메소드의 스택 영역에 저장되는 외부 변수들에 대해서는 참조만 가능하고 값 변경은 불가 → final or effectively final 변수만 사용 가능한 이유 외부 Reference type 변수에 대한 변경은 힙 메모리 데이터를 변경하는것이기 때문에 가능 (변수 초기화 같은 스택 참조값 변경은 동일하게 불가) 위 현상들의 이유는 람다가 실행될때 람다 캡처링이 일어나면서 발생하는 현상 람다 캡처링이 일어나게되면 람다의 새로운 스택을 생성..
예제 코드 https://github.com/cobiyu/MockitoSample Test Double이 왜 필요한 지부터 시작하는 기본적인 테스트 코드부터 한 단계씩 발전시켜나가며 Mockito의 어노테이션들의 정확한 쓰임새에 대해 살펴보겠습니다. github에 케이스별로 파일별로 구분 지어 놨으니 참고 부탁드립니다. Test Double (Mockito) 스프링과 Junit을 이용해서 테스트 코드를 작성하다 보면 테스트 환경(database, api)을 구현하는 코드까지 작성해야 하고 실제 테스트할 코드보다 환경을 구현하는 코드가 훨씬 더 복잡해지게 됩니다. 이런 문제 영역을 해결하기 위해서 테스트 더블 이라는 것이 나왔고 Java진영에서는 대표적으로 Mockito가 있습니다. Mockito의 어노테..
@NoargsConstructor(AccessLevel.PROTECTED) 와 @Builder를 함께 사용할때 주의할 점에 대해서 서술합니다. "왜" 안되는지와 "왜" 이렇게 해결 할 수 있는지에 대해 집중하여 서술합니다. 1. 왜 NoargsConstructor(AccessLevel.PROTECTED)를 사용하는가? @NoargsConstructor(AccessLevel.PROTECTED) Entity나 DTO를 사용할때 @NoargsConstructor(AccessLevel.PROTECTED) 어노테이션을 많이 사용하는 편입니다. 기본 생성자의 접근 제어를 PROTECTED로 설정해놓게 되면 무분별한 객체 생성에 대해 한번 더 체크할 수 있는 수단이 되기 때문입니다. 예를 들어 User라는 Class..
예제는 모두 Github(https://github.com/cobiyu/CompletableFuture)에 있으니 참고 바랍니다. 문제가 되는 상황 Micro Service Architecture를 구성하게되면 여러 API로 나뉘어 지는 만큼 API끼리 서로를 호출하는 상황이 많이 발생하게 됩니다. 그리고 자연 스럽게 아래 예제와 같은 문제가 발생하게 됩니다. public class SyncTest { Logger logger = LoggerFactory.getLogger(this.getClass()); public Integer goodsPriceApi() throws InterruptedException { logger.info("goodsPriceApi start"); TimeUnit.SECONDS..
