정준원의 개발 일지

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

Controller 테스트1. test 패키지와 파일 생성.2. 만만한 HealthCheck부터 시작!3. API 테스트에 많이 사용되는 mockMvc 사용.@SpringBootTest@AutoConfigureMockMvc@AutoConfigureTestDatabasepublic class HealthCheckControllerTest { @Autowired private MockMvc mockMvc; }4. mockMvc를 통해 호출(GET 방식), 응답이 200인지 확인.@Testvoid 헬스_체크_응답이_200으로_내려온다() throws Exception { mockMvc.perform(get("/health_check.html")) .andExpect(status().isOk(..

Service 리팩토링get과 find를 구분하는 컨벤션!find는 null을 반환할 수 있어 Optional로 받는 경우가 많음.get은 데이터가 없으면 에러를 던진다는 의미가 내포됨.해당 컨벤션에 따라 네이밍 변경!public Optional getById(long id){}-> public Optional findById(long id)public UserEntity getByIdOrElseThrow(long id) {}-> public UserEntity getById(long id) {}  User 서비스 자체에서 create가 유저를 생성한다는 의미를 내포함.public UserEntity createUser(UserCreateDto userCreateDto) {}-> public UserEn..

1. UserRepository 테스트 생성 2. 테스트를 위해 @DataJpaTest(showSql = true) 를 붙여줌. 3. test 설정을 위해 test-application.properties를 생성  3-1. 작성(복붙) 4. UserRepository가 Jpa가 H2랑 제대로 연결되었는지 확인을 위한 테스트 생성  4-1. User Entity를 적당히 생성.  4-2. User Entity save 호출  4-3. assertThat을 통해 not Null 이면 성공 5. 우리가 궁금한 것은 findByIdAndStatus 메서드와 findByEmailAndStatus 메서드가 제대로 동작하는지 여부임. A) findByIdAndStatus 정상 조회  A-1. User Entity를 ..

Builder생성자를 유동적으로 사용 가능해짐.객체 생성을 유동적으로 할 수 있음.일부 파라미터를 놓치는 휴먼 에러가 발생할 수 있음. 장점생성자를 하나로 관리할 수 있다.긴 파라미터를 정리할 수 있다. 단점종종 필요한 파라미터를 누락할 경우 컴파일러가 캐치 못하는 경우가 있음. 엔티티Entity는 Jpa와 관계 없다.도메인 엔티티와 DB 엔티티를 구분할 수 있다. 도메인 엔티티비즈니스에서 어떠한 문제를 해결하기 위해 만들어진 모델.비즈니스 로직을 갖고 있고, 식별 가능하며, 생병주기를 갖고 있음.보통 개랍에서 얘기하는 Entity는 도메인 Entity임. DB 엔티티데이터베이스에서 표현하려고 하는 유/무형의 객체를 구별한 것. 도메인 Entity -> 클레스로 표현, 비즈니스 영역을 해결하는 모델.영속..

의존성Dependency = couplingA는 B를 사용하기만 해도 의존한다고 할 수 있음. 의존성 주입Dependecy Injection : 의존성을 약화시키는 테크닉직접 new해서 인스턴스화하는 것이 아니라 외부에서 넣어주는 것.의존성은 완전 제거할 수 없음. (객체나 시스템 간의 협력을 부정하는 것임.)대부분의 디자인 패턴과 설계는 의존성을 낮추기 위해 고민한 결과물인 경우가 많음. 의존성 역전Dependecy Injection(DI) != Dependency Inversion(SOLID-DIP)의존성 역전은 **화살표의 방향을 바꾸는 테크닉**모듈 간의 상하 관계 같은 것도 포함하는 개념상위 모듈은 하위 모듈에 의존해서는 안됨.상위 모듈과 하위 모듈 모두 추상화에 의존해야 함.추상화는 세부 사항..

개념SUTSystem under test : 테스트 하려는 대상 BDDBehaviour driven development (given - when - then)TDD에서 추가로 하는 내용어디에 어떻게 넣을지 고민할 때 도움이 됨.3A (Arrange - Act - Assert) 와 동일시봐도 됨. Interaction Test (상호작용 테스트)대상 함수의 구현을 호출하지 않으면서 그 함수가 어떻게 후출되는지를 검증하는 기법일반적으로 메서드가 실제로 호출되었는지 검증하는 것은 좋은 방법이 아님.캡슐화에 위배됨. 상태 검증 vs 행위 검증상태 검증(state-based-verification)어떤 값을 시스템에 넣었을 때 결과값과 기댓값을 비교 행위 기반 검증(behaviour-based-verificat..

필요성테스트 코드는 왜 필요한가?레거시 코드 : 테스트 루틴이 없는 코드. 다만, 이 정의는 다소 불완전하다.Regression : 정상 동작하던 코드가 이번 배포로 동작하지 않음.수정이 무서워지게 됨.좋은 아키텍처를 유도 좋은 아키텍처란? : SOLIDSOLID와 Test는 서로 상호 보완적인 관계를 갖는다.테스트의 목적은 회귀버그 방지와 좋은 설계SOLID가 지켜지면 좋은 설계가 되고, 이로 인해 회귀 버그가 생기는 것을 막을 수 있다.단일 책임 원칙클래스 하나에 테스트 클래스 하나가 생김.테스트 작성 시 테스트가 많아져 무슨 목적의 클래스인지 눈에 안 들어옴이때가 클래스를 분할해야하는 시점자연스럽게 책임이 분배됨.개방 폐쇄 원칙테스트와 프로덕션 컴포넌트를 나눠 작업하게 되고 필요에 따라 컴포넌트를 ..