kkoon9

코프링으로 개발 시 마주친 에러 관련 포스팅입니다. 개발 환경은 다음과 같습니다. Spring Boot Version : 3.0.1 Java Version : 17 Kotlin Version : 1.8.21 Kotest Version : 5.5.5 배경 저는 mocking할 때 any()를 많이 사용했었습니다. 하지만 saveAll()은 any()로 mocking하려고 하면 다음과 같은 에러가 발생합니다. Not enough information to infer type variable S 해석해보자면 정보가 불충분하여 변수 S에 대한 타입을 추론할 수 없다라는 뜻입니다. 원인 다음과 같이 save mocking은 에러를 발생하지 않습니다. save의 파라미터는 S entity 입니다. cafeRepo..

배경 request body 필드들을 유효성 체크를 하고 싶었습니다. java spring boot 환경에서는 다르게 코프링에서는 몇 가지 문제가 발생해서 이번 포스팅에서 해당 문제들을 정리하려고 합니다. 개발 환경은 다음과 같습니다. Spring Boot Version : 3.0.1 Java Version : 17 Kotlin Version : 1.8.21 Kotest Version : 5.5.5 추가로, 아래 의존성을 추가해주셔야 합니다. // validator implementation("org.springframework.boot:spring-boot-starter-validation") 1. NotBlank not working 첫 번째로는 jakarta.validation.constraint..

배경 Spring Boot Version : 3.0.1 Java Version : 17 Kotlin Version : 1.9.20 m1인 local 환경에서 Spring Cloud Gateway를 사용할 때 아래와 같은 문제가 생깁니다. Unable to load io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider, fallback to system defaults. This may result in incorrect DNS resolutions on MacOS. 이걸로 인해 InvocationTargetException도 발생하게 되는데요. 사실 Spring Boot 2.7 버전까지는 에러가 발생하지만 잘 동작했었습니다. 허나, Spring..

배경 validator를 따로 분리하는 작성을 수행하였습니다. 이 때, 예외가 없다면 리턴값이 없는 메서드로 구성했었습니다. 이 validator 클래스를 사용하는 service Test 내에서는 해당 validator를 mocking해서 테스트하려고 했습니다. package com.laboratorykkoon9.kotlinspring.cafe.service import com.laboratorykkoon9.kotlinspring.cafe.repository.CafeRepository import org.springframework.stereotype.Service @Service class CafeValidator( private val cafeRepository: CafeRepository, ) { ..

코프링으로 개발 시 마주친 bean name 충돌 관련 포스팅입니다. 개발 환경은 다음과 같습니다. Spring Boot Version : 3.0.1 Java Version : 17 Kotlin Version : 1.8.21 배경 레거시 API와 분리하기 위해 API를 버저닝하기로 결정했습니다. Repository는 같이 쓰되, Service 레이어와 Controller 레이어는 버전을 나누기로 했습니다. 다음 이미지는 Controller 레이어의 버저닝 디렉터리 예시입니다. CafeController에서 버전만 v2로 바꾸고, 실행시켜보면 다음과 같은 에러가 발생합니다. 에러메시지를 읽어보면 BeanDefinition이 Conflict났다고 알 수 있습니다. BeanName은 @Component이 붙은..

단위 테스트 책을 읽고 비즈니스 로직의 흐름을 담당하는 service layer(비즈니스 로직 흐름을 담당하는 layer) 테스트 코드를 시도했던 내용을 담는 포스팅입니다. 단위 테스트 - 예스24 소프트웨어 개발에 있어 단위 테스트는 이제 선택이 아니라 필수가 됐다. 단위 테스트에 대한 오해를 바로잡고, 올바른 단위 테스트에 대한 원칙, 테스트를 작성하는 스타일과 효과적인 테스트 www.yes24.com 배경 제가 시도 및 고민했던 부분은 다음과 같습니다. 1. mock을 어디까지 쓸 것인가 2. 조회 테스트 필요 유무 3. repository 테스트 필요 유무 1. mock을 어디까지 쓸 것인가 단위 테스트 책에서 보면 mock의 사용을 최소화하라고 나와있습니다. 초반 부분만 봤을 때에는 비즈니스 로..

코프링으로 개발하면서 테스트 작성 중 create table 에서 마주한 에러를 포스팅해봤습니다. 배경 단위테스트 책을 참고하며 service layer 테스트를 위해 table에 insert하는 상황이었습니다. 테스트 환경이기 때문에 spring.jpa.hibernate.ddl-auto 옵션은 create로 했습니다. 허나 테이블 생성 쿼리에서 문법 오류가 발생했습니다. columnDefinition 문제 사실 @CreatedDate 어노테이션만 사용해도 됐는데, columnDefinition까지 설정해줬던게 문제였습니다. H2에서는 해당 entity 설정이 문법 오류를 발생시키는 모양입니다. package com.laboratorykkoon9.kotlinspring.common import jakar..

코프링으로 개발하면서 zeroDateTime(0000-00-00 00:00:00)인 LocalDateTime 값 관련해서 마주한 내용을 포스팅해봤습니다. 배경 as-is(파이썬) 코드로 되어 있는 배치 스크립트를 코틀린으로 이전하는 작업에서 발생했습니다. as-is 코드에서 사용하지 않는 row는 수정 시간을 zeroDateTime으로 변경해주는 로직이 있었습니다. SQL문으로 직접 수정해주었기 때문에 별 문제 없는 로직이었습니다. 허나, 스프링 환경에서 적용하려고 하니 다음과 같은 문제가 발생했습니다. 바로 LocalDate 타입에서 month와 day 값의 최소값이 1인 점이었습니다. import java.time.LocalDate import java.time.LocalDateTime fun mai..