Interface를 이용하여 완충재를 두고 테스트를 할 때는 테스트를 위한 mock 구현체를 이용하여 final 메소드를 stub하는 것을 피한다는 것은 이해를 했는데요. 갑자기 드는 생각이 결국 프로젝트가 배포될 때는 SystemUuidHolder라는 구현체를 사용하게 되고 그러면 해당 클래스의 대한 테스트도 진행해야 하나요? 진행한다면 해당 클래스는 UUID를 사용하고 있으니 final 메소드를 stub하는 상황을 피할 수 없게 되는건가요?

제목 그대로 언제 사용하시는지에 대해 얘기를 나눠보고 싶어 질문 남깁니다.제 경우는 영속성 계층에 새로운 객체가 추가될 때 (RDB에 레코드를 추가할 때) new 키워드를 사용하여 id 값을 생성자로 받지 않는 생성자를 열어두고,존재하는 도메인 엔티티 혹은 영속성 엔티티를 영속성 계층으로부터 불러올 때는 정적 팩터리 메서드를 사용하는데강의를 진행하시면서 습관적으로 생성자 대신 static 메서드를 통해 생성 하시더라구요, 강사님만의 명확한 기준이 있으신지 궁금합니다.

스프링 컨테이너가 뜰 때 Jpa의 Repository 인터페이스 하위 타입을 스캔하여 빈으로 등록하는 것으로 알고 있어서 ProductRepository가 자동으로 스캔이 될텐데 @Repository 어노테이션을 붙이신 이유가 궁금합니다

안녕하세요! 먼저 항상 좋은 강의 감사드립니다! 저도 작은 경험 이지만 개발을 하면서 서비스 단의  로직을 분리 (강의에서 말씀 해주신 것 처럼 책임을 분리할 정도)해야 하는 상황인 경우, 이렇게 하는게 맞는지는 모르겠으나, Point1. ServiceUtil 클래스를 정의하여 컴포넌트로 주입받아 사용하거나 (실무에선 이렇게 사용)Point2. 학습시에는 Facade 패턴을 이용하여 서로 다른 서비스들의 상위 퍼사드 객체를 만들어서 사용한 적이 있습니다.(물론 퍼사드 패턴의 경우, 두 로직이 완전히 다른 맥락인 경우에 사용하는 것 같습니다.. 강의 예제와 같이 결합도가 높은 경우가 아니라..)그런데, 강의에서는 Factory 객체를 만들어서 (마치 제가 ServiceUtil을 만들어서 사용하는 것 처럼 - 사실 이름만 다르지 같습니다)사용하시는 모습을 보여주셨는데, Q1. 강사님께서는 실무에서 서비스의 책임을 분리할 때 주로 이런식으로 Factory 클래스를 분리하여 사용하시는지 궁금하고,  Q2.그렇게 Factory 클래스로 책임을 분리했을 때, 이 Factory 클래스는 Controller / Service/ Repository 그 어느것도 아니게 되는데, Spring WEB mvc 레이어 아키텍쳐 상으로 어떤 Layer의 어떤 입장의 객체로 인지하고 사용해야 하는지 여쭙고 싶습니다. 감사합니다.

 async function PostDetailPage({ params }: any) { const post = await getPost(params.id); return ( <div> <h1>Posts/{post.id}</h1> <div> <h3>{post.title}</h3> <p>{post.created}</p> </div> </div> ); }PostDetailPage 에서 params을 콘솔에 출력하면 id값이 나오는거는 주소에서 받아오는건가요?

안녕하세요. 좋은 강의 잘 듣고 있습니다 ^^ 강의에서 private method 테스트를 해야되는 상황이라면객체를 분리해야되는 상황이라고 말씀을 주셨는데실무에서는 꼭 분리를 해야되는 상황이 아닐수도 있을텐데1)실무에서는 private method 에 대한 테스트는 거의 작성안하나요? 2)레거시 프로젝트를 맡았을때 public method 에 대한 테스트를 작성하기에는 많은 작업이 필요하다면 private method 라도 테스트 코드를 작성하는게 좋을거 같은데 이런 경우도 작성을 안하나요?3) private 함수를 변경하는경우 해당함수만 테스트하고 싶을거 같은데 이런경우는 어떻게하나요? 

포스, 키오스크, 이외 다른 주문 엔드포인트로부터 주문이 들어왔을때 똑같은 서비스를 사용할 경우 그 서비스에서 사용하는 서비스dto로 변환해주어야 하기 때문에 컨트롤러 dto와 서비스dto를 분리해주는게 좋다로 이해했는데 맞을까요?

안녕하세요MySql 중형 테스트 연동을 보고 있습니다IntegrationTest 상속받아서DayoneTestApplicationTests 실행하면ERROR: for dwneh9yir6mh_local-db-migrate_1 Cannot start service local-db-migrate: error while creating mount source path '/c/경로/dayonetest/db/migration': mkdir /c: file existsCreating dwneh9yir6mh_local-db_1 ... doneERROR: for local-db-migrate Cannot start service local-db-migrate: error while creating mount source path '/c/경로/db/migration': mkdir /c: file existsEncountered errors while bringing up the project.코드들도 혹시 옥타 있을까봐 복붙으로 수정하였고test docker-compose.yaml 노션에 있는 거 그대로 복붙했습니다.도커 데스크탑에서 컨테이들이 올라오는 건 확인했는데시작이 안되네요앞선 local compose.ymal은 호스트 경로는 문제가 없었습니다.도커 컴포즈 도커 데스크탑 모두 업데이트 리스타트 해보고볼륨 내려보고 이미지 삭제하고 초기화도 해도 안되는데 무슨 문제인지 알 수 있을까요?

netlify를 배포 했는데 경고와 빌드 문제 인 것 같습니다 어떻게 하면 될까요?

Order를 생성하면서 이에 대한 서비스 반환 값으로 orderResponse를 반환하는 것을 볼 수 있었습니다.얕은 지식으로는 Create에 해당하는 내용은 201 상태코드와 URI.Created 를 사용하여 헤더에 Location을 명시해주고 "/api/v1/orders/" + id형태로 제공해주는 것이 좋은 것으로 알고 있었는데 생성 시에도 반환 값을 제공해주시는 이유가 있을까요?

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

테스트의 질문과는 좀 벗어나는 질문입니다만.. 궁금해서 여쭤보게 되었습니다!간단한 프로젝트를 구성하는 과정에서 Beverage라는 인터페이스를 만들어 추상화를 진행하고 해당 인터페이스는 get의 행위만 가지고 있었습니다.그리고 추가된 라떼와 아메리카노 둘 다 같은 속성이지만 구현을 통해서 두 개의 구성 클래스를 만들어 예제를 진행하였는데요.이에 다음과 같은 의문점이 생겼습니다.인터페이스가 get이라는 행위만 가져도 사용해도 괜찮은지. 지금과 같은 상황에서는 확장에서의 의미로 추상 클래스가 더 괜찮을 것 같은데 사용하지 않은 이유가 있으신지 궁금합니다ㅎㅎ좋은 강의 제공해주셔서 감사합니다~

혹시 넷플릭스로 Netlify 배포 가능할까요?

안녕하세요, 우빈님 너무 좋은 강의를 올려주셔서 잘 듣고 있습니다! Repository 구현 시 @Repository 어노테이션을 붙이는 이유가 궁금합니다.스프링 데이터 JPA를 사용할 경우 스프링이 만들어서 제공하는 컴포넌트를 사용해서 @Repository 를 생략해도 되는 거로 알고 있는데, 사용하시는 이유가 따로 있는지 궁금합니다.

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요. [공지] 제가 9/27 ~ 10/9 약 2주간 해외 여행을 가게 되어, 해당 기간 동안은 질문에 대한 답변이 불가합니다. 🥲 질문을 남겨주시면 10/10 이후로 순차적으로 확인하고 빠르게 답변드릴 수 있도록 하겠습니다. 너른 양해 부탁드리며, 강의를 수강해주시는 분들 모두 항상 감사드리고, 또 응원합니다. 🙌🏻 다시 코드를 보니 헷갈리는게 있어서 질문 드립니다!OrderService에서 createOrder를 할때 내부적으로 중간 매핑 엔티티인 OrderProduct가 생기는 이유가 Order엔티티에 있는 create메서드를 호출 빌더로 Order객체를 생성할때 orderProducts리스트 초기화orderProducts는 casecade = CasecadeType.ALL이 되어있으므로 2번 과정으로 인하여 객체가 생성되고 db에 저장이 맞을까요? 감사합니다!

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요. [공지] 제가 9/27 ~ 10/9 약 2주간 해외 여행을 가게 되어, 해당 기간 동안은 질문에 대한 답변이 불가합니다. 🥲 질문을 남겨주시면 10/10 이후로 순차적으로 확인하고 빠르게 답변드릴 수 있도록 하겠습니다. 너른 양해 부탁드리며, 강의를 수강해주시는 분들 모두 항상 감사드리고, 또 응원합니다. 🙌🏻 안녕하세요 우빈님! 강의 수강 중 궁금한 점이 생겨서 질문드립니다!지금까지 작성한 테스트들은 Production Code가 제대로 동작하기 위해서 ~~했을때 이러한 결과가 나와야한다! 식의 검증을 제대로 한다는 느낌을 받았습니다. 그래서 후에 코드를 수정하고 테스트를 다시 돌려보며 로직이 제대로 실행하는지를 검증하며 테스트의 이점을 잘 활용할 수 있겠다라고 생각하였습니다. 하지만 Mock에 대해 학습을 하면서는 이 테스트가 효과적인 테스트인가? 하는 의문이 조금씩 들기 시작하였습니다.물론 지난 시간 학습하였던 OrderStatisticsService 의 경우 테스트의 주된 목적은 총 금액 확인이었으므로 sendEmail 메서드의 Stubbing은 왜 하는지 이해하였습니다. 이번 강의를 들으면서 몇가지 의문점이 생겼는데 다음과 같습니다!sendEmail을 Stubbing하면 당연히 반환되는 값은 Ture 일 것Mock객체의 defaultAnswer에 의해서 mailSendHistoryRepository.save()의 반환값이 null이어도 테스트가 성공함로직을 원하는대로 수행하기 위해 메서드가 몇번 호출되는지 검증을 할 필요가 있는가?  전체적으로 Stubbing을 얼마나 잘하는지에 대한 테스트를 한다는 느낌을 받았습니다!혹시 기능에 대한 사용법을 알려주시려고 한것인지 아니면 실무에서도 이러한 테스트를 작성하는지, 작성한다면 verify()를 사용할때 메서드 호출횟수를 검증하여 얻고자 하는것은 무엇인지, 그리고 모든 메서드를 Sutbbing하게 되면 해당 코드에서 무엇을 검증하는것인지 궁금합니다! 감사합니다! 

.env 생성하고 axios.js에서 process.env.REACT_APP_MOVIE_DB_API_KEY를 찾지 못하고 있어요process.env.REACT_APP_MOVIE_DB_API_KEY=00000000

충분히 공감가고 이해되는 내용입니다! 좋은 내용 설명해주셔서 감사합니다!그렇다면 responseDto도 순수 서비스 응답과 ,각 컨트롤러 별 응답으로 구분하는게 좋을까요? 

예전에 조영호님의 '오브젝트' 서적을 읽고 "어떻게 비즈니스 모델을 더 변경에 부드럽게 설계할 수 있을까?"에 고민을 했습니다. 그때의 기억으로는 "역할은 책임을 위한 최소한의 정보만 가지고 있자"라고 제가 이해를 했고 @Entity가 달린 class를 "역할"로 보고 코드 작성을 하니 1개의 RDB Table이 2개 이상의 Entity Class로 매핑이 되었습니다.평소에 1개 Entity Class가 1개 Table와 매핑하는 것과 달라 괴리감이 들었습니다. 핵사고날 아키텍쳐를 적용하면 비즈니스 모델과 JPA의 Entity를 분리할 수 있지만 팀원들과의 합의도 필요해서 적용할 수 없었고 주니어라 해당 기술 도입으로 생산성이 올라갈 것이라고 장담할 수도 없었습니다. 두서가 없이 말이 많았는데 궁금한 점은!"RDB의 1개 Table을 2개 이상의 Entity로 매핑해서 운영을 하는게 보편적인 방식인가요?" 입니다. ++ 개인적인 질문입니다만 객체의 협력 관계를 먼저 설계하는 것과 DB 설계하는 것 어떤 것이 우선인가요?

안녕하십니까! 항상 좋은 강의 감사드립니다.ApiResponse에 HttpStatus를 필드로 두어,응답 상황에 따라 적절한 HttpStatus를 설정하도록 강의에서 의도해주셨습니다.실제로 저도 이런식으로 사용하고 있었는데요,그런데 이번에 테스트 하면서 알게 된 것이지만,ApiResponse에 HttpStatus를 넣어준다고 하더라도실제 응답 HTTP의 status에는 반영이 되지 않고,단순히 응답 body에만 설정한 status가 쓰여졌습니다.아래 첨부한 사진을 보면 201로 setting 하였지만,실제 응답은 200 인걸 예로 확인할 수 있었습니다.그래서 제가 질문 드리고 싶은 부분은,"그렇다면 응답을 어떻게 해야 하는가?" 입니다.ApiResponse라는 공통 응답을 한번 더 ResponseEntity<> 안에 감싸서 보내는 방법을 생각해 볼 수 있을 것 같습니다.단 이방식은 ApiResponse의 status를 ResponseEntity의 status로 동기화 시켜주는 작업과,그리고 응답 타입도 ResponseEntity<ApiResponse<>>이런식으로 depth가 2번 생기게 되는 단점이 있을 것 같습니다.(depth가 2번 생긴다는게 올바른 표현인지는 모르겠으나,서비스 응답을 ApiResponse로 한번 감쌌는데,이를 한번 더 ResponseEntity로 감싼 것을 2번의 depth로 표현하였습니다.)두 번째로는 오직 응답 바디에 있는 값 만을 사용하기로 프론트와 규약을 정하고 사용하는 방법이 있을 것 같습니다.이렇게 하면 굳이 한번 더 ResponseEntity<>로 감쌀 수고는 덜어질 것 같습니다. 제가 생각한 방식은 이렇게 두가지가 있을 것 같고, 제가 속한 회사에서 기존 방식은 2번째 방식을 사용하고 있었습니다.그런데 , 저는 신규 프로젝트에 투입되어 있는 상황 이여서 코드를 제가 원하는 대로? 짤 수 있는 상황인데요,,그래서 위 두가지 방식중에 어떤것이 좋을지,혹은 더 나은 방식이 있을지 질문 드리고 싶습니다.제가 3개월 차라 .. 경험이 많이 부족해서,,강사님 경험에 기반하여 답변해주시면 정말 감사하겠습니다.