비동기 함수 테스트 강의를 따라했을 때 제 컴파일러에서는 오류가 발생합니다. 다른 테스트 케이스들 말고 아래 두 케이스에서만요.test('okPromise 테스트', () => { const okSpy = jest.fn(okPromise); return okSpy.then((result) => { expect(result).toBe('ok'); }) }) test('noPromise 테스트', () => { const noSpy = jest.fn(noPromise); return noSpy.catch((result) => { expect(result).toBe('ok'); }) })각 테스트 별 에러 메세지는 다음과 같습니다.'Mock<Promise<string>, [], any>' 형식에 'then' 속성이 없습니다.ts(2339)'Mock<Promise<never>, [], any>' 형식에 'catch' 속성이 없습니다.ts(2339)코드를 동일하게 작성했음에도 불구하고, 어떤 문제로 위 에러가 발생하는 걸까요?

안녕하세요.UserRepository를 구현하는 구현체로는 UserJpaRepository를 사용하는 UserRepositoryImpl와 테스트용 구현체인 FakeUserRepository가 있는데요. TDD라는게 단순 객체지향적인 설계를 잘하는 방법론이라면 납득이 가는데, 실제 서비스 되어야 할 코드가 잘 동작하는지 검증하기 위함이라는 관점에서는 조금 궁금한점이 생겨 질문드립니다. FakeUserRepository는 UserRepository의 계약을 잘 이행하고 테스트도 성공하도록 잘 구현하였습니다.그런데 실제 서비스에 사용될 UserRepositoryImpl는 한번도 검증된 적 없는데 테스트를 통해 어떻게 소프트웨어가 변화함에 있어서 확신을 가질 수 있나요? UserRepositoryImpl 내부 구현이 변경되었을때 여전히 FakeUserRepository만 테스트를 실행할텐데 어떤식으로 개발 과정에서 확신을 얻을 수 있는지 궁금합니다. 추가적으로 TDD의 역할에는 어떤 구현 기술에 대해 잘 사용되었는지에 대한 검증은 포함되지 않나요? 예를 들어 스프링 데이터 JPA를 잘 사용하였는지..? 예를 들자면 저는 TDD를 해본적은 없지만 실제 실행되는 인프라 계층을 실행해볼 수 있는 샘플 테스트코드 개념으로 만들어서 사용하고 있는데요. 제가 개발하고 있는 기업용 솔루션이 버전이 높아짐에 따라 워낙 무거워져서 로컬 PC에서 WAS를 기동하는데에만 2분이 넘기 때문에 최소한의 인프라계층 혹은 인프라계층의 협력 클래스들정도는 테스트 코드로 직접 테스트해볼 수 있도록 테스트 코드를 작성해 두었습니다. 이렇게 해두면 어떤 이슈가 발생했을때도 곧바로 쉽게 테스트가 가능하니까요. 물론 DB 개발서버 장비에 연결하고 더미데이터를 가지고 실행하는 식으로요. 이번 강의에서 H2를 통한 인프라 테스트 강의까지가 딱 제가 하고 있는 테스트들이었는데요. 중간에 놓친것인지 테스트가 무거워진다는 설명만 하고 그뒤로는 리팩토링과 함께 인프라 레벨의 테스트는 언급을 안하셔서 제가 생각하는 구현 기술을 잘 사용하여 실제 서비스되는 인프라 모듈을 직접 테스트 하는 부분은 어떻게 해야할지 궁금합니다.

확장자를 TS로 변경했을 때 코드에는 ESM의 import, export를 사용했는데 왜 package.json파일의 ESM 관련 옵션인 "type": "module"을 제거하는지 궁금합니다. GPT의 답변에 의하면TS 파일은 컴파일 과정에서 CommonJS나 ESM이나 알맞게 변환을 하기 때문에 해당 옵션이 필요 없고, Jest와의 호환성을 위해 "type": "module"을 제거해주는 것이고,JS파일은 기본적으로 CommonJS모듈 시스템을 사용하기 때문에 import문을 사용했으면 ESM방식으로 해석하도록 명시하기 위해서 "type": "module"을 추가한다.라고 설명을 해주는데 그럼 JS 파일의 경우 Jest와의 호환성을 고려하지 않는건지.. 이해가 잘 되지 않습니다. 혹시 설명을 해주실 수 있을까요?

환경 : mac os저의 경우에 npx ts-jest config:init 명령어를 통해 생성한 jest.config.js 파일의 내용이 다음과 같이 강의 영상과 달랐습니다./** @type {import('ts-jest').JestConfigWithTsJest} **/ module.exports = { testEnvironment: "node", transform: { "^.+.tsx?$": ["ts-jest",{}], }, };강의 영상 내용에 맞춰서 preset: 'ts-jest' 설정을 추가해주어 Jest가 TypeScript 파일을 컴파일하고 실행할 수 있도록 해주니 잘 동작합니다. 

안녕하세요 제로초님. 강의 교안이 어디있는지 모르겠습니다.

커밋을 강의 중간에 계속 하던데 깃허브에는 커밋이 한개밖에 없네요 어떻게 알수있을까요

좋은 강의 감사합니다. UserEntity 클래스에 있는 from 메서드는 static, toModel 메서드는 그렇지 않습니다. 둘의 차이와 from 메서드를 static 으로 설정한 이유가 있을까요?

현재 CertificationServiceTest를 할 때 MailSender를 주입받는 것이 아닌 FakeMailSender를 주입받아서 테스트를 진행하는데MailSender를 만든 이유가 의존성을 역전시키기 위해서 만든 것인데 FakeMailSender를 사용하게 되면 의존성 역전 원칙이 적용된 것이 아니지 않나요???FakeMailSender는 mock으로 사용하고 있지만 구현체이니까 MailSender를 사용해야 되는 것이 아닌가요??그냥 테스트 목적으로 필드 값들이 잘 전달되는지 확인하기 위해서 사용하기 때문에 상관이 없는 건지 궁금합니다. MailSender 인터페이스를 이용한다면 검증 부분에서 다운 캐스팅을 해줘야 하기 때문에 사용하지 않은 건가요???

섹션 6 진화하는 아키텍처의 3번째 강의인 핵사고날에 대한 사견 강의 중 8분 9초에 강사님께서 시스템이 명확할 때, 추상화가 너무 많이 되어있다면 쓸모없는 구역이라고 말씀하시고 Spring/JPA/RDB 이 3개를 쓸게 명확하다면 레이어드 아키텍처로 개발하라고 말씀하셨는데 그럼 기술 스택이 명확한 상황이라서 레이어드 아키텍처로 개발을 시작하게 된다면 전체적인 강의 통틀어서 말씀하셨던 의존성 역전, JPA에 종속적인 문제, 도메인 중점 개발 이런 것들이 필요 없어지게 되는걸까요?레이어드 아키텍처 개발이든 핵사고날 아키텍처로 개발을 하든 도메인을 중심으로 개발하는 것이 중요하다고 생각합니다. 하지만 의존성 역전으로 인한 추상화나 그로 인한 테스트 작성이 쓸모가 없어지게 되는걸까요?

섹션3 - 테스트추가하기: h2를 이용한 service 테스트 에서UserService의 create 를 테스트하기 위해 Mock으로 주입된 JavaMailSender의 send를 다음과 같이 given 절에 추가하셨습니다.  https://tecoble.techcourse.co.kr/post/2020-09-29-compare-mockito-bddmockito/에 따르면 BDDMockito는 given-when-then 구조의 시나리오 기반 테스트를 진행할 때, 시나리오에 맞게 테스트가 읽힐 수 있도록 도와주는 역할이라고 하였습니다. 따라서 저는 해당 코드를 when 절에 추가하였는데, 다른 분들은 어떤 의견이신지 궁금합니다...! 

안녕하세요 좋은 강의 잘 듣고 있습니다. 사소한 질문이지만요..! <테스트 추가하기:mockmvc 를 이용한 controlelr 테스트 강의>의 13:00 에서요 ObjectMapper 를 @Autowired 로 주입받아서 쓰지 않고 생성하셔서 쓰는 이유가 있을까요? 각각은 어떻게 다르고 장단이 있나요.  미리 감사합니다.

안녕하세요? 강의 잘 듣고 있습니다강의보면서 코드를 따라치고 싶은데, 코드는 따로 제공되지 않는건가요?

많은 도움을 얻어가는 취준생입니다. 다름아니라 본 영상(레이어드 아키텍처의 문제점과 해결책) 9분30초의 구조는 DDD라고 볼 수 있나요?감사합니다.

테스트 중에 고민되는 부분이 생겨서 문의드립니다.A서비스의 a()메서드에서 B서비스의 b()메서드를 호출하고 있고, B서비스의 b()메서드에 대한 단위 테스트가 이미 완료된 상황을 예시로 들겠습니다. 이미 b()메서드에 대한 테스트는 끝났으니, A서비스 단위 테스트 시 a()가 b()를 호출해서 생기는 결과에 대해서는 따로 검증이 필요하지 않을까요? 저는 b()를 호출하는 것까지가 a()의 책임이기 때문에 a()를 테스트하려면 b() 호출에 따른 검증 과정도 필요하다고 생각됩니다.하지만 이 경우 여러개를 의존하는 클래스에 대한 테스트 시, assertThat()과 같은 검증 코드 및 테스트 코드가 뚱뚱해지는 일이 발생합니다.혹은 테스트 시 a()에서 B서비스의 b()를 호출했는 지에 대해 Mock라이브러리의 verified를 통해 검증 가능한 것으로 알고있는데, 모키토 같은 외부 라이브러리를 사용하지 않고 테스트를 작성하고 싶어 고민됩니다.  결국 A서비스를 단위 테스트할 때 어디까지 테스트하는 것이 적절한 책임 분배?인지 알고 싶습니다.

안녕하세요. 관련 내용을 듣다가 궁금한 것이 생겨 질문드립니다.해당 강의를 듣다가 궁금한 것이 생겨 질문드립니다.찾아보니 DDD나 헥사고날 아키텍처에서 request / response 객체 <-> 도메인 객체 <-> entity 객체 간의 mapping이 일어나는 것을 볼 수 있는데요..이런 경우 controller, service, infral layer가 모두 mapper 관련 라이브러리 객체나 직접 구현한 mapper 객체를 들고 변환시켜주는 구조는 별로 좋지 못한 구조일까요?제 개인적인 의견으로는 결국 지금 구조에서 response / request 객체나 entitiy 객체가 domain 객체로 변환시켜주기위해 domain 객체에 의존성이 생기는 구조인데 mapper 객체를 쓰면 이런 객체간의 의존성을 최소화시킨다는 점에서 장점이 있을 것 같은데요.. 물론 정답은 없겠지만, 의견이 어떠신지 궁금하여 질문드립니다.

2부 마지막 리팩토링 0:49에서, "service인데 controller.port를 잘못 참조했다"라고 하셨는데요.이를 수정하고 나신 후인 3:30쯤에서도, 여전히service(의 UserServiceImpl)가 controller(의 Port의 UserService)에 의존하는 상황이지 않나요?제 생각엔 Port 자체를 controller 밖으로 꺼내는 게 의미상 더 좋지 않을까 싶은데 어떻게 생각하시나요?

"테스트 추가하기: h2를 이용한 repository 테스트" 편의 10:39 에서, "잘 커버된 것 같아요"라는 말을 하셨는데 이 상황을 이해하기가 어렵습니다.PostEntity 와 관련된 테스트가 없는데 PostEntity 의 라인 14%가 충족되었다고 나옵니다. 이런저런 이유로 그냥 채워지는 경우도 있습니다만, 하단의 첨부 사진과 같이 제 화면에서는 0%로 보입니다. 혹시 이 차이가 왜 발생하는지 아시나요? (저는 temurin-17, IntelliJ Ultimate 2014.1.4 을 쓰고 있습니다) UserEntity 에도 동일한 질문을 드릴 수 있을 것 같습니다.UserRepository 인터페이스는 메서드가 존재하는데 0개 있다고 표기되고 있습니다 ("0/0"). 왜 이렇게 나오는지 아시나요?UserRepository 는 사실상 아무 메서드도 없다고 판단되었기 때문에 커버리지가 100% 로 나온 듯 합니다. 그 위의 PostRepository 도 (테스트가 없는데) 100% 로 나왔으니 그렇게 해석하는게 맞는듯 합니다. 따라서 이 대목에서 커버리지가 아무것도 측정되지 않은 것 같습니다. (위 1,2 질문의 대답에 따라 달라질수도 있겠지만) 여기까지 제가 이해한게 맞을까요?

강의 열심히 들으며 실습하고 있습니다!헥사고날 아키텍처를 학습하며 적용해 보니 다양한 어려움이 생기더라구요 ㅠㅠ혹시 entity 내의 from과 to 메서드조차 분리하고자 할 때 궁금한 점이 생겼습니다.Entity 내의 from과 to 메서드로 domain ↔ entity를 변환하는 것을 Converter 클래스를 통해 관심사를 분리하는 것이 괜찮은지?만일 분리한다면, Converter interface의 위치는 domain 하위 port package일지, infrastructure 하위 port를 만들어 사용할지? (Impl 구현체는 따로 패키지를 생성할 예정입니다)강의 열심히 듣고 보내주신 책도 잘 받아 열심히 공부하고 있습니다 ㅎㅎ책에 껴주신 Thankyou.java 파일 잘 받았습니다! 감사합니다

DB에 의존하지 않는 FakeRepository를 구현할 때 JPARepository의 작동 원리를 고려하여 직접 코드를 작성하는걸로 이해했는데, 그렇다면 FakeRepository에 복잡한 쿼리를 쓰는 메소드가 필요하다면 그때마다 코드를 만들어줘야 하나요?? 예를 들면) 아래와 같은 메소드를 FakeRepository에서 구현하여 Test하고 싶을 때는 어떻게 하는 건가요?@Query(value = "SELECT * FROM (SELECT * FROM customer ORDER BY like_total DESC) WHERE ROWNUM <= 3", nativeQuery = true) List<UserEntity> findTop3ByLikeTotal();

혹시 저 파일에서 찾기 단축키가 뭔지 알 수 있을까요???너무 유용해보이는데 여기저기 찾아봐도 잘 못 찾겠어요...