kth990303의 코딩 블로그

우테코 프로젝트에서는 Spring Data JPA를 사용하고 있었다. Spring Data JPA를 이용하면 인터페이스 생성 만으로도 SimpleJpaRepository에 내장된 다양한 CRUD 메서드를 활용할 수 있고, 추가로 커스텀 메서드도 편리하게 만들 수 있다는 장점이 존재한다. 그러나 Spring Data JPA는 동적 쿼리를 사용하기 어렵고 복잡한 쿼리는 @Query 어노테이션을 이용하여 JPQL을 직접 작성해주어야 한다는 문제점이 존재한다. 따라서 이번 기회에 queryDSL을 적용하여 컴파일 시점에 문법 오류를 잡아낼 수 있게 하고, 복잡한 쿼리를 리팩터링하는 데에 도전해보았다. 특히 위처럼 DTO를 반환하는 repository method의 경우 @Query로 작성하면 DTO 패키지명을 ..

코틀린 프로젝트에서 kotest로 테스트 코드를 짜다가 통과해야 할 테스트가 통과하지 않는 현상을 마주치게 됐다. 우리는 StringSpec과 유사한, 중첩되지 않은 구조에서 Given - When - Then 구조의 BehaviorSpec 스타일로 테스트를 마이그레이션하고 있었다. 위 두 테스트 코드는 아예 동일하다. 그저 계층만 나뉘게 바뀌었을 뿐. 구조에 따라 계층을 나누기만 하고, 순서 변경이라든지 코드의 변경이 없었으니 테스트는 당연히 문제 없이 통과할 줄 알았다. 그런데 결과는? Tests Failed... 당연히 WAITING에서 PASS로 변경될 줄 알았는데 Given에서 진행해준 update가 진행되지 않고 WAITING인 상태로 테스트가 진행됐다. 심지어 코드 변경은 전혀 없고 구조에 ..

우리는 @SpringBootTest 어노테이션을 이용하여 손쉽게 통합테스트를 진행할 수 있다. 하지만 @SpringBootTest의 webEnvironment 설정에 따라 테스트 격리가 잘 되지 않는 현상을 발견할 수 있다. 왜 그런 것일까? @SpringBootTest의 webEnvironment @SpringBootTest를 파고 들어가면 아래와 같이 webEnvironment 세팅을 볼 수 있다. 기본값은 MOCK이다. WebApplicationContext를 로드하지만, 내장된 서블릿 컨테이너가 아닌 MOCK 서블릿을 제공한다. 실제 서블릿 환경에서 테스트를 진행해보고 싶다면 RANDOM_PORT나 DEFINED_PORT로 진행해주어야 한다. RANDOM_PORT랑 DEFINED_PORT는 위 사..

Spring Boot 환경에서 여러 협력 객체들이 존재하는 통합테스트는 빈을 호출하기 위해 @SpringBootTest를 사용하는 경우가 많다. 그리고 협력 객체들이 많을 때에는 테스트를 위한 기대 행위 전처리 작업을 mockito를 이용하여 stub을 통해 test double을 만들어주는 경우들이 존재한다. @SpringBootTest와 함께 사용한다면 @Mock, @InjectMocks 대신 @MockBean을 주로 사용할 것이다. 그런데 테스트 코드를 작성하는 방법에 대해 공부하던 도중 @SpyBean이라는 어노테이션을 알게 됐다. 이 어노테이션은 뭐하는 애일까? 그리고 어떻게 사용하는게 좋을까? @MockBean 개인적으로 나는 웬만해선 @MockBean 대신 실제 객체를 사용하는 방식을 사용하..

배포 환경에서, 그리고 개발하면서 api를 맞춰보면서 특정 문제가 발생했을 때 그에 대한 기록을 남겨두면 이후에 그 기록을 바탕으로 대처를 할 수 있다. Spring에서는 다양한 logging configurations들을 제공한다. log4j, logback, log4j2들이 대표적이다. 이번 포스팅에선 log4j2를 선택한 이유와, 개발 및 배포환경에서 각각 다른 log4j2 yml을 어떻게 만들었는지 작성해보도록 하겠다. logback vs log4j2 log4j는 2015년에 서비스가 종료됐고, 오래된 로그 프레임워크이기 때문에 제외하도록 하겠다. logback log4j 개발팀이 제작하여 기본적으로 log4j와 비슷하지만 성능이 향상됨. spring-boot-starter-web의 기본 로깅 프..

스프링에서 코틀린을 사용할 때, 테스트 도구로 JUnit뿐만 아니라 kotest를 사용할 수 있다. kotest는 다양한 테스트 스타일을 제공한다. JUnit과 유사한 Annotation Spec, String Spec, 그리고 우리가 흔히 사용하는 given when then 스타일을 사용할 수 있도록 Behaivor Spec을 제공해주기도 한다. DCI 패턴을 활용할 수 있도록 Describe Spec도 제공해준다. 이번 시간에는 kotest에서 제공해주는 spec을 살펴볼 것이다. kotest의 장점 JUnit, Mockito를 사용할 경우 Kotlin DSL을 사용하지 못한다는 단점이 존재한다. kotest를 활용하면 kotlin DSL을 사용해 더 코틀린스러운 테스트를 작성할 수 있게 된다. 위..

친구와 얘기하던 중, Spring IoC, DIP 개념에 대한 얘기가 나왔다. 이 개념들은 구글링하면 워낙 잘 정리된 글들이 많아 별도로 작성하지 말까 고민도 했다. 하지만 해당 개념들은 객체지향에서 매우 중요하기 때문에 한번쯤은 포스팅하는 것이 좋을 듯하여 정리해보려 한다. IoC(제어의 역전) Inversion of Control, 즉 IoC는 제어의 역전이라고 번역된다. 쉽게 말하자면 어떤 객체에 대한 관리를 나 대신 다른 애한테 맡긴다는 것이다. 스프링을 쓴다면 스프링에게 특정 객체의 생성과 소멸을 빈으로 등록해 맡겨주는 것으로 생각하면 된다. 즉, 제어권을 내가 아닌 스프링 컨테이너에게 빈의 생성, 의존 관계 설정을 맡기는 것이므로 IoC가 이루어지는 것이다. 스프링을 사용하지 않는다고 하더라도..

flyway는 DB 형상관리 오픈소스 툴이다. 즉, db schema가 변경이 발생할 때 flyway라는 툴로 관리를 할 수 있는 것이다. 이번 포스팅에서는 flyway 적용 방법에 대해 아주 간단히 알아볼 것이다. Flyway 사용 이유 배포 환경(prod)에서는 ddl-auto를 create, update, create-drop을 지양해야 한다. 배포된 db의 데이터들이 모두 증발될 수 있기 때문이다. 따라서, db schema 변경이 있을 때에 우리가 직접 배포 환경 db에 접속하여 schema를 작성해주어야 한다. 이는 매우 번거로우며 위험성 또한 높다. Flyway를 사용하면 이러한 번거로운 작업이 사라지게 된다. 변경된 스키마를 한눈에 확인할 수 있어 스키마 버전 관리에 용이해진다. flywa..

조회 쿼리로 결과가 나올 때, 데이터가 너무 많으면 사용자가 보기에도 불편하고 로딩에도 오랜 시간이 걸린다. 그렇기 때문에 많은 사이트들에선 많은 데이터들을 페이지로 나누어서 관리한다. 스크롤을 내릴 때마다 데이터를 추가로 로드하는 무한 스크롤 방식을 사용하거나, 이전/다음 페이지로 이동하는 방식이 주로 사용된다. 이렇게 페이징 기법을 적용하려면 전체 데이터 개수와 요구되는 페이지넘버에 따른 인덱싱 계산을 해주어야 하는데, 실수할 여지도 많고 꽤나 번거롭다. 다행히 Spring Data JPA에서는 스스로 페이지 관련 인덱싱을 계산해준 결과를 반환해주는 기능을 제공해준다. 이번 포스팅에선 Spring Data JPA의 Pageable, Page에 대해 알아보고 MVC 패턴에서 Pageable이 어디까지 ..

Spring Data JPA에는 Auditing 기능을 편하게 다룰 수 있도록 @CreatedDate, @LastModifiedDate 어노테이션을 제공해준다. 그리고 생성일자, 수정일자 컬럼은 웬만한 모든 도메인에 있으면 로깅 및 사용자 입장에서도 간편하다. 따라서 보통 BaseEntity라는 생성일자, 수정일자가 들어있는 상위 엔티티를 만들고 상속 구조를 이용하는 방법을 진행한다. 이번 포스팅에서는 이 방법에 대해 기록해보려 한다. 개발환경 Spring Boot 2 버전 Spring Data JPA lombok 프로덕션 코드 BaseEntity @EntityListeners(AuditingEntityListener.class) @MappedSuperclass @Getter abstract public..