합니다, 개발공부📝 합니다, 개발공부📝

https://dodop-blog.tistory.com/285 Service Layer의 단위테스트 작성 : (1) Mockito ① 서비스 계층을 테스트 하기 위해서 실제 Repository를 DI하게 된다면 단위테스트를 작성하기 위한 F.I.R.S.T원칙을 위배하게 된다. Fast : @SpringBootTest 어노테이션이 해당 어플리케이션이 모든 빈을 Ioc dodop-blog.tistory.com https://dodop-blog.tistory.com/287 Service Layer의 단위테스트 작성 : (2) Fake 객체 https://dodop-blog.tistory.com/285 Service Layer의 단위테스트 작성 : (1) Mockito ① 서비스 계층을 테스트 하기 위해서 실제..

https://dodop-blog.tistory.com/285 Service Layer의 단위테스트 작성 : (1) Mockito ① 서비스 계층을 테스트 하기 위해서 실제 Repository를 DI하게 된다면 단위테스트를 작성하기 위한 F.I.R.S.T원칙을 위배하게 된다. Fast : @SpringBootTest 어노테이션이 해당 어플리케이션이 모든 빈을 Ioc dodop-blog.tistory.com https://dodop-blog.tistory.com/286 Service Layer의 단위테스트 작성 : (1) Mockito ② https://dodop-blog.tistory.com/285 Service Layer의 단위테스트 작성 : (1) Mockito ① 서비스 계층을 테스트 하기 위해서 ..

https://dodop-blog.tistory.com/285 Service Layer의 단위테스트 작성 : (1) Mockito ① 서비스 계층을 테스트 하기 위해서 실제 Repository를 DI하게 된다면 단위테스트를 작성하기 위한 F.I.R.S.T원칙을 위배하게 된다. Fast : @SpringBootTest 어노테이션이 해당 어플리케이션이 모든 빈을 Ioc dodop-blog.tistory.com 이제 우리는 의존 관계에서 독립적으로 ServiceLayer계층을 테스트 진행했다. 하지만 Mock객체는 생성비용이 많이 드는데 그 이유는 @MockBean 의 경우에 컨텍스트를 새로 만들기 때문 이다. Application Context 만약 RepositoryLayer 테스트는 @DataJpaTe..

서비스 계층을 테스트 하기 위해서 실제 Repository를 DI하게 된다면 단위테스트를 작성하기 위한 F.I.R.S.T원칙을 위배하게 된다. Fast : @SpringBootTest 어노테이션이 해당 어플리케이션이 모든 빈을 Ioc 컨테이너에 등록하고 테스트를 진행하므로 테스트가 느려진다. Independent : repository와 의존관계를 갖는 테스트 를 작성하게 된다면 테스트 대상이 Service계층의 테스트는 Repository에 의존적이 되므로 독립적인 테스트작성이 어려워 진다. Repeatable : DB에 의존적인 테스트는 한번 ID가 생기면 중복되므로 반복 테스트가 어렵다. 테스트 어노테이션 @SpringBootTest 통합테스트, 전체 Bean전체 @WebMvcTest 단위테스트, ..

https://dodop-blog.tistory.com/229 예외처리전략 (Exception Handler) 스프링에서 예외처리를 해주자. 예외발생 데이터타입을 일관된 형태로 생성해서 반응하도록 설정해준다. Error Response 먼저 예외의 형태를 잡아주는 클래스를 작성해준다. 메세지와 상태, 시간정 dodop-blog.tistory.com 이전 글에서 예외처리 전략을 이용하여 예외발생 데이터타입을 일관된 형태로 생성해서 반응하도록 설정하는 방법을 알았다. 그런데 여기서 모든 customException을 RuntimeException을 상속받아 중복되는 NotFoundException의 경우에도 모두 ControllerAdvice(GlobalExceptionHandler)에서 일일이 처리해주어야..

프로젝트 엔티티를 구성할 때 엔티티에 중복으로 created_at, updated_at 등의 생성 시간, 업데이트 시간을 column으로 중복적으로 필요해질 때가 있다. 이럴 때 JPA Auditing을 사용해서 시점 생성을 자동화 할 수 있다. BaseTImeEntity 생성 @MappedSuperclass @EntityListeners(AuditingEntityListener.class) public abstract class BaseTimeEntity { @CreatedDate @Column(nullable = false) private LocalDateTime createdAt; @LastModifiedDate private LocalDateTime updatedAt; public LocalDat..

jpa에서 ID를 이용하여 객체를 가져오는 방법에는 getById(), findById() 두가지 방법이 존재한다. getById() public void get_activity_with_id(Integer id) { //given //when Activity activity = repo.getById(id); //then } getById()는 원래 메소드인 getOne()이 deprecated되어 대체된 메소드로 내부적으로 EntityManager.getReference() 메소드를 호출하여 엔티티가 아닌 프록시를 반환한다. 이 때문에 실제로 사용하기 전에는 데이터 베이스에 접근하지 않고 실제로 사용될 때 프록시에서 데이터 베이스에 접근하려고 할때 데이터가 존재하지 않는다면 EntityNotFound..

테스트 코드를 작성하던 중 다음과 같은 오류를 맞닥뜨리게 되었다. 테스트 메소드를 읽지 못하는 메세지였다. Junit5 import org.junit.jupiter.api.Test; class Junit5Test { @Test void test() { //... } } 단일 jar였던 Junit4와는 다르게 Junit5는 Junit Platform, Junit Jupiter, Junit Vintage 세가지로 이루어져있다. Junit Platform : JVM에서 동작하는 테스트 프레임워크 (TestEngine 인터페이스 정의) Junit Jupiter : Junit5 기반의 테스트 실행 (TestEngine의 실제 구현체) Junit Vintage : Junit3 및 Junit4 기반의 테스트 실행 (..