정준원의 개발 일지

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가 지켜지면 좋은 설계가 되고, 이로 인해 회귀 버그가 생기는 것을 막을 수 있다.단일 책임 원칙클래스 하나에 테스트 클래스 하나가 생김.테스트 작성 시 테스트가 많아져 무슨 목적의 클래스인지 눈에 안 들어옴이때가 클래스를 분할해야하는 시점자연스럽게 책임이 분배됨.개방 폐쇄 원칙테스트와 프로덕션 컴포넌트를 나눠 작업하게 되고 필요에 따라 컴포넌트를 ..

테스트란?인수 테스트 : 사람이 직접 사용해 보면서 준비된 체크리스트를 체크자동 테스트 : 미리 짜여진 코드를 돌려서 결과값과 예상값을 비교. DB를 사용하는 경우에는 H2를 활용해 RDB를 InMemory에 잠깐 띄워서 테스트함.@ExtendWith(SpringExtension.class)를 사용해서 테스트용으로 스프링을 띄움  TDD1. RED -> 깨지는 테스트를 먼저 작성한다.일부러 실패하는 테스트를 만듦. (테스트를 돌려서 실패하는 것까지 확인하기.) 2. GREEN깨지는 테스트를 성공시킨다. 3. BLUE리팩토링한다.복잡한 코드에서는 파괴적일 수 있음. 하지만, 이전 단계에서 그린을 확인했으니 상관없음. TDD는 이 과정을 무한..

상황레거시 코드가 많음. 서비스는 운 좋게도 매년 성장했음.개발자가 2배 늘었지만, 개발 속도는 1.2배 정도에 그쳤음.(커뮤니케이션 비용 등) 서비스 장애를 우려해서 배포를 신중하게 했음.회귀 버그가 발생할 가능성이 생겼고, 이를 두려워 하게 됨.회귀 버그 : 잘 동작하는 기능이 다시 버그가 발생하는 상황테스트 자동화 도입으로 회귀 버그를 줄이고자 했음테스트 자동화로 인해 커버리지를 높일 수 있음.외부 API 연동, DB 연동 등 쉽지 않은 테스트 케이스를 마주하게 됨.mockito나 H2를 활용해서 처리함.서비스는 단순한데, 이 단순한 서비스 로직 확인을 위해 테스트를 작성하는 일로 인해 더욱 복잡하게 되어 버림.스프링 부트와 H2를 사용하니 100개가 넘는 테스트를 하는 데 2분이 넘게 걸리게 됨...