서비스 테스트 시 Repository 상속해서 FakeRepository를 생성자 주입을 통해 진행한다는 내용에 대해서는 이해하고 실습해 보았습니다.그런데 만약 Repository 메서드 중 JPA의 on 절을 이용한 join을 사용해 데이터를 가져오는 경우 FakeRepository의 내부 구현이 궁금합니다내부에 Id와 List를 통해 해당 엔티티에 대한 정보를 저장할 수 있지만, Join을 하는 경우 외부 테이블의 정보가 필요하기 때문에 이를 Fake하고 싶을 때는 어떻게 해결할 수 있는지 알려주시면 감사하겠습니다.

service 레이어는 repository 보다 상위 레이어에 있습니다.일반적으로 service 레이어는 repository 를 주입받아서 사용됩니다.OOP 원칙에서도 상위레이어는 하위레이어를 알아도 괜찮은것으로 알고있습니다. 반대로 하위레이어는 상위레이어를 알아서는 안됩니다.'외부 연동을 다루는 방법' 강의 1:53 ~ 2:04 에상위 레이어인 Service 가 infraStructure 에 의존하는 모습을 보이기때문에 라고 하셨습니다. 이말을 해석하면, 앞으로 변경될 코드에서는 UserService 는 interface 인 UserRepository 를 의존하게됩니다. 그러나 자세히 들어가면 service 레이어가 UserRepository 에 의존하는것이 아닌 의존성역전을 통해 그의 Impl 을 받게됨으로 약결합이 되게됩니다. 그러므로, service 가 interface 인 UserRepository 에 의존하는건 아니기때문에 service 패키지로 해당 interface 를 옮긴것인지 궁금합니다.

안녕하세요. 우선 강의 너무 잘 들었습니다.설계를 개선하며 소형테스트를 풍부하게 작성할 수 있다는 것을 보고 이를 체화하려고 공부중인데요,강의에서 배운것을 적용하다가 막힌 곳이 있어서 질문드립니다.우선, 저는 강의와 유사하게 Repository를 추상화해서 프로덕션(~RepositoryImpl)과 테스트 환경(Fake~Repository)을 다르게 가져가고 있고, 막힌 부분은 아래와 같습니다.프로덕션에서 groupBy를 사용하고, Dto로 바로 조회하는 방식으로 프로덕션 Repository에 코드를 작성한 부분이 있는데,이를 Fake Repository에서 작성하려니까 막막하더라구요왜 FakeRepository에 작성하려 하냐면, 제가 이해하기로는 FakeRepository를 구현해야 Service 레이어를 테스트할 때, 소형테스트로 작성할 수 있다고 이해를 했기 때문입니다. 막힌 부분에서 여러 고민해보다가, 다양한 조건절과 그룹핑이 들어간 쿼리는 어떻게 Fake Repository에 작성해서 테스트할 수 있을까? 하는 궁금증이 생겼습니다. 그래서 질문입니다.Fake Repository를 사용해서 일부 Service 레이어의 로직을 테스트할 수 있지만, 좀 더 복잡한 쿼리들은 Fake로 구현(stream, filter등을 사용해서)하기 어려우니, Fake로 구현하지 않고 중형 테스트로 테스트한다.그리고 위의 기준이 소형테스트로 테스트할 지, 중형테스트로 테스트할 지 고려할 기준이 된다..?저는 위와같이 생각이 이어지는데, 혹시 옳은 생각일까요? 아님 열심히 Fake로 구현을 해봐야하는 것일까요?그것도 아니라면 다른 방법이 있을까요? 강사님은 복잡한 쿼리들을 어떻게 하시는지 궁금합니다..!열심히 강의해주셨는데, 막상 적용해보려니 쉽지 않아서 민망합니다..답변 미제공 강의지만, 호옥시나 하는 마음에 질문 남깁니다.🥹좋은 강의 감사드립니다 

중형 테스트는 멀티 스레드, 멀티 프로세스를 허용하는 테스트라고 이해했는데 그 설명을 하시면서 "멀티 프로세스와 멀티 스레드를 사용할 수 있는 완화조건이 생기죠. 이는 다시 말해 h2 같은 테스트용 DB를 사용할 수 있게 된다는 의미입니다." 라고 하셔서요! 혹시 h2를 사용하려면 멀티 스레드나 멀티 프로세스 환경에 있어야 한다고 이해해도 되는걸까요? "h2는 멀티 스레드, 멀티 프로세스 환경에 있어야 하기 때문에 h2를 사용하는 순간 중형 테스트로 보면 된다"로 이해하면 될까요??

섹션 21부 실기 수업 - 어쨌든 테스트 코드에서 사용하는 기존 프로젝트 위치가 혹시 어디 있나요?

UUID에 대해 제가 작성한 로직의 방향이 맞는지 확인해 보고싶은데, 문제관련 코드는 어디에 있나요 ?

안녕하세요! 강의 너무 잘듣고있습니다.소스코드 내에서 UuidHolder와 User의 관련 의존성 방향에 대해 질문이 있어 글 남깁니다public static User from(UserCreate userCreate, UuidHolder uuidHolder) { return User.builder() .email(userCreate.getEmail()) .nickname(userCreate.getNickname()) .address(userCreate.getAddress()) .status(UserStatus.PENDING) .certificationCode(uuidHolder.random()) .build(); }위 코드에서 Parameter값을 통해 User 객체가 UuidHolder 라는 클래스에 의존하게 되는데요. UuidHolder 의 경우 common 패키지의 application layer에 존재하는 것으로 알고 있습니다. Domain layer의 User객체가 application layer의 객체에 의존하는 것이 parameter형태로는 허용이 되는지 질문드립니다.

안녕하세요, 강의 잘보고 필요할떄마다 계속 보고 있습니다.현재 강의에선 도메인 객체와 영속성 객체(Entity class)를 분리해서 사용하여서 문제가 없을 것 같은데,보통 Entity class 에서 ID를 자동으로 생성하는 경우가 대부분이어서, 생성자를 생성 할 때, ID를 포함하지 않는 생성자를 많이 만드는 것으로 알고 있습니다.이 때, 테스트코드는 어떻게 작성해야할까요?소형 테스트를 작성한다면 H2 같읕 데이터베이스에서 객체를 가져오지 않는 한 아이디가 존재하지 않을텐데아이디로 비교하지 말고 다른 값들만 비교해야할까요?그렇다면 로직내에 findById() 같은 메서드로 객체를 불러와서 처리하는 경우가 있다면 어떻게 하시는지 궁금합니다. 객체의 아이디가 없으므로 로직내에서 아이디를 가져오거나 비교하는 경우가 있다면, NPE가 발생하여 테스트가 제대로 진행이 되지 않는 경우가 많을 것 같습니다.다들 보통 어떻게 하시는지 궁금하여 질문 남깁니다감사합니다

안녕하세요. 강의에 매우 깊은 감명을 받고 토이 프로젝트에 말씀해주신 부분들 적용해보고 있습니다.강의에서 가이드 주신대로 유효성 검증에 대한 테스트도 mock 라이브러리 없이 순수 자바 코드로 해보고 있습니다.기존 코드에서는 입력값 유효성 검증을 위해 @Valid 어노테이션을 사용했는데요. 스프링부트를 실행시키지 않으니 @Valid 어노테이션이 정상작동을 안해서 테스트를 작성하는데 어려움을 겪고 있습니다....ㅎㅎ그래서 유효성 검증을 하는 코드를 직접 작성해야 하나 고민하다가 질문을 남기게 되었습니다. 강사님께서는 유효성 검증에 대한 테스트 코드를 작성하는데 어떤 방법을 사용하시는지 궁금합니다.(@Valid는 자바 표준 스펙으로 알고 있어서 스프링을 실행시키지 않아도 방법을 잘 찾아보면 가능할 것 같다 라고도 생각하고 있습니다.)  

안녕하세요 강의 잘 보고 있습니다.다름이 아니라 이렇게 H2등을 쓰지않고 테스트 할 경우, 많은 테스트 데이터들을 셋업하는 것이 힘들것 같은데 보통 어떻게 처리하시나요?h2등을 사용한다고 하면 강의에서 알려주신 것 처럼 보통 .sql을 실행시켜서 사용할텐데,이렇게 소형테스트들에 테스트데이터를 java code로 반복문 돌면서 생성하자니 좀 번거러운 것 같은데 혹시 다른 방법이 있을런지 혹은 어떻게 하시는지 궁금하여 여쭤봅니다.환절기가 다가오는데 더위 조심, 감기 조심 하시길 바랍니다.감사합니다.

강의를 굉장히 감명 깊게 보고 Spring 기반으로 되어 있는 레거시 프로젝트에 도메인을 분리하고 유닛 테스트를 넣는 작업을 하고 있습니다. 여기에서 가장 답답한 게 단순한 유닛 테스트임에도 빌드 타임을 그대로 기다려야 한다는 점인데요. 비록 빌드 캐시 덕에 아주 오래 걸리는 건 아니긴 해도 몇십 ms면 끝날 테스트를 몇 초씩 기다려야 하는 점이 많이 답답합니다. 시간 상으로는 인메모리 db를 띄우는 것과 별 차이 없는 것 아닌가? 하는 생각이 들 정도예요. (물론 테스트 코드를 작성하기 쉬운 구조가 좋은 코드 구조라는 명제에는 이견이 없기 때문에 별 차이가 없다 하더라도 계속 진행할 예정입니다.)선생님께서도 담당하시던 시스템에 유닛 테스트를 붙이는 작업을 하셨다고 들었는데 이러한 부분은 어떻게 극복하셨는지 궁금합니다.

혹시 다음 강의는 어떤 내용으로 준비중이신지 궁금합니다

안녕하세요. 강의가 너무 재미있어 시간가는 줄 모르고 1편, 2편 강의 완강 하고있습니다. 2편, 테스트 관련해서 실습을 하던 중 고민이 생겨서 질문을 올리게 되었습니다.자바/스프링으로 코딩을 하다가 A Service와 B Service가 의존관계를 갖게 된다면 어떻게 해야할지가 너무 고민이여서요.만약 2편에 있던 도메인 User, Post에 User의 프로필 이미지 업로드기능, Post의 이미지 업로드기능이 있다고 할 때, File의 정보를 저장할 수 있는 File 도메인이 있어야 한다고 생각합니다.File에 대응하는 FileService를 만든다고 가정 하였을 때 DB 등에 파일의 정보 데이터를 저장하는 FileRepository, 파일을 업로드 하는 FileUploader를 만든 후 의존관계가 이런형태로 구성 되어야 한다고 생각합니다. FileService에 saveAndUpload() 라는 메서드가 있고 이 메서드를 공통으로 사용하고 싶을 때 UserServiceFacade, PostServiceFacade와 같은 형태로 퍼사드를 써야할지, UserService, PostService 에 각각 업로드 메서드를 구현을 해야할지 고민이 됩니다. Facade와 같은 형태로 코드를 작성하게 된다면 User, Post가 아닌 파일이 필요로 하는 도메인이 추가 될 때 마다 Facade를 작성해줘야하는 번거로움이 있을 것 같고,Service 각각에 업로드 메서드를 구현하자니 반복적인 코드가 들어가는 것이 마음에 조금 걸려서 질문드립니다.

답변해줘요.....................

서비스에서 사용하는 모델인 거 같은데제 생각입니다.다른 의견 적어주시면 감사합니다.

해당 강의에서 도메인 모델과 영속성 객체를 구분하는 리팩토링을 진행하셨는데요.리팩토링 이후 영속성 컨텍스트를 통한 더티체킹을 활용하지 않고, 대신 save 메서드를 매번 호출해 주시는 방법으로 변경하셨더라구요.도메인 모델과 영속성 객체의 의존성을 제거하기 위해서 더티체킹 기능도 사용하지 않는건가요?

안녕하세요 재밌고 알찬 강의 제공해 주셔서 감사합니다.jpa 와 같이 findById 같은 기본적으로 제공해주는 메서드는 따로 테스트를 안해봐도 될거 같은데..queryDsl 식으로 커스텀한 쿼리를 호출할때 테스트 방법은 어떻게 해야할지 궁금합니다.. h2 와 같은 임베디드디비로 쿼리 조건과 데이터가 잘 나오는지 테스트도 짜고, 다른 인터페이스를 상속받은 구현체의 메서드에서 메모리를 사용해 stream 과 filter 식으로 데이터를 반환하는 구현체를 테스트로 다시 넣어야하는지.. h2로 테스트코드를 짜고, 확인 후, 해당 테스트 코드는 지워버려야 하는지.. 강사님은 어떻게 하고 있는지 궁금합니다.. 감사합니다. 

따라해보려고 합니다! 토이프로젝트 소스 공유 부탁드려요!

Post를 수정한다면 새로 만들어지는 것이 아닌 존재하는 객체를 변경하는게 조금 더 잘 읽힐것 같은데 불변객체로 만드신 이유가 궁금합니다. 혹시 실무에서도 도메인 엔티티에 대해 불변으로 사용하나요?

안녕하세요! 강의 잘 보고 있는 수강생입니다강의를 보니 Mockito나 Junit을 전혀 사용하지 않고 전체 테스트를 작성하시는 것을 보고 많은 감명을 받았습니다.실무에서도 Mockito나 Junit을 전혀 사용하시지 않는지, 사용한다면 어떤 상황에서 사용하시는지 여쭤보고자 글을 남기게 되었습니다.좋은 하루 보내세요!