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

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 단위테스트, ..

프로젝트 진행하면서 git branch 전략을 적용하여 develop에서 개발을 진행하고 PR이 승인되면 main 으로 코드를 merge 하고 있는데, 개발을 잘못하여 main 브랜치에서 작성하고 commit 하였다는 것을 알게 되었다. ① commit 복사 //단일 커밋 복사 git cherry-pick commit hash //여러 커밋 복사 git cherry-pick commit hash1 commit hash2 //hash1과 hash3 사이의 모든 커밋 복사 (^을 붙이지 않으면 앞의 commit은 포함되지 않음) git cherry-oick commit hash1^...commit hash3 이런 경우에 git cherry-pick을 이용해서 이 문제를 해결할 수 있다. 단일 커밋을 복사할 ..

자바 8부터 지원하는 Stream은 컬렉션, 배열 등에 대해서 요소들을 하나씩 참조하여 반복적 처리를 하는 기능이다. 스트림은 내부 반복을 통해서 작업을 처리하기 때문에 for문을 사용하는 것 보다 간결하게 식을 표현할 수 있다. Stream 스트림의 특징은 다음과 같다. 원래의 데이터를 읽기만 할 뿐 기존 데이터를 변경하지 않음 일회성이므로 재사용이 불가능하다. 필요하다면 정렬된 결과를 반환하도록 한다. (스트림의 생성을 반복적으로 이용하면 연속적으로 사용할 수 있다) 스트림 생성, 중개연산, 최종연산 의 구조를 지니고 있다. ( 스트림생성().중개연산().최종연산() ) 병렬 스트림은 여러 쓰레드가 작업한다. (parallelStream()으로 병렬 스트림 작성 시 parallelStream().fi..

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..