정준원의 개발 일지

아키텍처갑자기 아키텍처?테스트는 품질을 위한 도구이면서, 설계를 위한 도구임.Testability를 높여야 설계를 위한 도구로 사용 가능.테스트와 설계는 상호보완적.테스트가 어렵다면 아키텍처가 정답을 알려줌. 개발하기 어렵다면, 테스트하기 쉽도록 개발하면 편하다. 아키텍트의 정의아키텍처란 어떤 비즈니스 문제를 해결하기 위해 준수해야하는 제약을 넣는 과정!아키텍처를 지키려고 하다보면 오히려 더 불편해짐.이로 인해 꼭 필요한 것이 아니라면 차라리 없는 것이 나을 수 있음.그럼에도 아키텍처를 사용하는 이유?아키텍처를 사용하기 전 문제 상황을 정확하기 인지하는 것이 중요함.꼭 써야하는 이유를 파악하고, 구성원들이 모두 동의해야함.아키텍처는 종착지가 아닌 여정에 가깝고, 고정된 산출물이 아니라 계속된 탐구 과정에..

각Service를 추상화 ServiceImpl로 구현체 이름을 변경Controller 패키지에Service 인터페이스 생성public interface UserService { User getByEmail(String email); User getById(long id); User create(UserCreate userCreate); User update(long id, UserUpdate userUpdate); void login(long id); void verifyEmail(long id, String certificationCode);}public interface CertificationService { void send(String email, long ..

service에 테스트코드 넣기 FakeRepository 구현public class FakeUserRepository implements UserRepository { private final AtomicLong autoGeneratedId = new AtomicLong(0); private final List data = new ArrayList(); @Override public Optional findById(long id) { return data.stream().filter(item -> item.getId().equals(id)).findAny(); } @Override public Optional findByIdAndStatus(long i..

mock, h2, SpringBoot 없이 테스트 작성하기. 대망의UUID가 등장!@Testpublic void User는_UserCreate_객체로_생성할_수_있다(){ // given UserCreate userCreate = UserCreate.builder() .email("kok202@naver.com") .nickname("kok202") .address("Pangyo").build(); // when User user = User.from(userCreate); // then assertThat(user.getId()).isEqualTo(0L); assertThat(user.getEmail())...

실습 2부 - 의존성 역전하기외부 연동들에 의존성 역전 사용!MailSenderRepositoryRepository 들의 네이밍 JpaRepository로 변경! 의존성 역전을 위해 인터페이스 만들기.UserRepository 인터페이스를 생성구현체 UserRepositoryImpl 생성구현체는 UserJpaRepository를 주입받음.  UserRepository는 infrastructure에 있을 경우 상위 모듈인 service에서 하위인 infrastructure를 의존하는 그림이 나오게 됨.따라서 서비스 하위에 외부 연동을 담당하는 port 패키지 생성 후 service에서 사용하는 인터페이스들은 port에 위치 시킴. 분리된 Repository에 따라 코드 수정post@Service@Requi..

패키지 리팩토링!1. 기존 프로젝트 코드들을 user 패키지를 생성하여 옮기기기존 구조 변경된 구조 2. 추가 리팩토링 진행model -> domaindto 네이밍 -> 제거(이미 역할을 내포하고 있음.)repository -> infrastructure 3. 리팩토링 후 테스트 재확인정상 동작하는 것을 확인! 4. 테스트의 구조 또한 위와 동일하게 변경 5. 리팩토링 후 테스트 재확인! 6. 끝!헥사고날과 같은 더 고도화된 아키텍처도 존재함.헥사고날은 도입에 너무 큰 리소스가 듦...강의 마지막 즈음엔 헥사고날과 같은 고도화된 아키텍처에 대해서도 학습 예정!

테스트의 범위ServiceImpl과 Domain을 중점으로 공부할 예정임.Controller와 RepositoryImpl은 아주 적게 다룰 것임.이유가 Controller는 요청을 받고 응답할 뿐이기 때문에 스프링에서 아주 잘 만들어 놨을 것이기 때문임.Repository에서도 마찬가지로 이미 JPA에서 잘 만들어 놨기 때문에 다룰 이유가 없다고 생각 됨. 낮은 커버리지 걱정걱정 : JPA 와 Spring 쪽 테스트를 안 하게 되면 커버리지가 너무 낮게 나옴.도메인 : 도메인이 그만큼 빈약하다는 의미경쟁력 : 서비스의 경쟁력을 의심해봐야 함. 실기 전 추가 사항 및 추가 내용JPA, Http 통신 등 외부 내용들은 의존성 역전 원리를 적용해 다룰 예정임.ServiceImpl -> Repository Se..

H2모든 테스트가 H2를 필요로 한다.H2를 사용하는 순간 중형 테스트가 된다.모든 테스트가 중형 테스트가 되었음...소형 테스트가 없음무거움...!설계가 잘못되었을 확률지금 작성한 테스트가 실제로 테스트가 필요한 본질이 아닐 확률 레이어드 아키텍처의 문제점레이어드 아키텍처유사한 기능들을 같은 계층으로 묶어 관리하는 방식의 아키텍처 구조의존성 역전이나 추상화 없이 바로 구현체를 사용하는 구조요청은 순차적이다Controller가 받아서 Service에게 전달Service는 비즈니스 로직을 처리 후 Persistence(JPA)에게 전달JPA는 Repository 데이터를 가져와 Service에게 전달다시 Service는 비즈니스 로직을 처리 후 Controller에게 전달Controller는 클라이언트에게..