강의 소스 코드를 다운로드 받아 압축 풀기를 하는데 99% 끝부분에서 특정 파일이 에러가 발생해 넘어가지지를 않습니다.건너띄기로 100% 완료하기는 했지만 찜찜해서 문의 드립니다. 

16강 '외부 연동을 다루는 방법'의 04:15에 보면,service.port 패키지로 이동한 UserRepository가 infrastructure에 있는 UserEntity에 의존하고 있는 상태입니다.아마 후속 강의에서 UserEntity에 대한 의존도 해소될 것으로 예상되지만, 여기에서도 언급은 해주시면 더 좋을 것 같습니다.

안녕하세요 좋은 강의 잘 들었습니다~!강의를 모두 듣고 제공해주신 프로젝트를 쭉 확인하고 궁금한 점이 생겨서 문의를 남겨봅니다저는 실무에서 도메인 모델과 엔티티 모델을 구분하지 않고도메인 모델에 JPA관련 어노테이션을 모두 허용한 상태로 개발해왔습니다물론 구분해서 개발해본적도 있었지만컬럼 변경 등 다양한 변경사항에 대응할 때마다 도메인 모델과 엔티티모델을 둘 다 확인하고 변경해야하는 번거러움?이 생겼던거 같아서 클래스가 좀 지저분해지더라도 도메인 모델 하나로 개발하고 테스트 코드를 작성해왔었습니다이번 강의에서 사용된 프로젝트의 경우모듈과 패키지가 나눠져있어서 도메인 모델과 엔티티 모델이 분리되어있는듯 보이지만 제가 사용했던 구조와는 다른점이 있었습니다..!도메인 모델은 강의에서 말씀하신 개념과 격벽그리고 행동에 대해 적절하게 표현하기위한 객체이지만 핵심 비즈니스 로직을 모두 포함하고 있는게 아니라 대부분 조회된 데이터를 개념에 맞게 변경하는 DTO? 역할을 하는것 같고 상태변경에 대한 로직은 엔티티에 구현하고 service 레이어에서 호출하는 방식으로 보여집니다그렇지만 처음 보는 코드가 잘 읽힐정도로 충분히 설득력있는 구조라고 생각이 듭니다..다만 테스트 코드가 있어야만 그 설득력이 완벽해질것 같다는 생각이 들었습니다그래서 해당 프로젝트 구조를 더 이해하고 학습하기위해 테스트 코드를 작성해보려고 합니다만약 저라면 ~Entity에 작성되어있는 상태변경에 대한 테스트 코드와 ~Service, ~Handler, ~Manager 등에 작성된 로직에 대한 테스크 코드를 작성할 것 같은데강사님은 이러한 구조에서 테스트 코드를 어디까지 작성하시는지 또는 어떻게 접근하시는지 궁금합니다~!

8. DB에 요청하여 데이터 update와 delete하기 이강좌가 런닝타임이 1시간이 넘는다라 표기됬음에도16분정도 시청하면 화면이 검게 변하면서  재생이 검은화면만 계속나오는데 강좌오류인가요? 아니면 표기상 미스가 난건가요??? 내용상 뒷부분이 끊겼는지 궁금해지네요

테스트 시나리오 유효하지 않은 경우는 언제 도출하나요?테스트 시나리오를 작성하기 전에 모든 경우의 수를 고려해서 작성해야할지 고민입니다.제가 개발하는 도메인을 명확하게 잘 모르면 이걸 도출해내기가 쉽지도 않고 시간이 너무 소요되더라구요. 어느정도 limit 시간을 잡으시고 점진적으로 못찾은 부분을 도출하시는지 의견이 궁금합니다.

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요. 안녕하세요.좋은 강의 재밌게 수강하고 있습니다!강의를 들으면서 의식적으로 테스트 코드를 작성하기 위해 노력하고 있습니다.  학습하다 보니 테스트 코드에 대한 부분을 정량적인 지표로 활용할 수 있는 커버리지라는 지표가 있다는 것을 알게 되었는데요. 제가 개발하는 부분은 도메인이 복잡한 프로젝트는 아니다 보니, 주로 Service Layer와 Presentation Layer 위주로 작성하게 되더라구요. queryDSL이나 native query를 이용해 복잡한 쿼리를 작성하게 되면, 가끔 Persistence Layer까지 작성하게 되는 것 같습니다. 그러다 보니, 도메인 패키지가 아닌 Config 등 global 패키지에 존재하는 코드나 Persistence Layer의 테스트 코드가 커버리지가 낮고, Persistence Layer의 커버리지도 낮아서 그런지 보통 프로젝트의 라인 커버리지가 60% 전후를 기록하고 있는 것 같습니다. 우빈님께서는 커버리지를 어떤 식으로 활용하시는지 궁금합니다! 커버리지 자체를 신경쓰기 보다는 말씀해주신 대로 미래를 위해 의미가 있는 테스트 코드를 작성하고 싶은데, 커버리지도 활용하는 방법이 있는지? 그리고 주로 어떤 레이어 위주로 테스트 코드를 작성하시는지 궁금합니다!읽어주셔서 감사합니다.

보통 구현 클래스 뒤에 Test를 붙이면 Idea에서 자동 추적을 해줘서 Test로 빠르게 이동이 가능한데,POST_specs 같이 만드신 이유가 있을까요?

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  BDD 설명하시면서 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장한다고 하셨는데요  작성한 테스트를 따로 문서화 하기도 하시는지 궁금합니다!

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!먼저 유사한 질문이 있었는지 검색해 보세요.서로 예의를 지키며 존중하는 문화를 만들어가요.  단위테스트할때 항상 궁금했던 점이단순한 CRUD도 테스트코드를 구현해주는 게 맞는걸까요?JPA 기능을 그대로 적는? 느낌이 나서 굳이 필요한 테스트코드인가 하는 생각이 항상 드는데 왜 구현했는지에 대한 시나리오를 @DisplayName 적곤 하지만 뭔가 불필요하다는 생각이 가끔 들기도 하는데 다 적는 게 맞는거겠죠??

강사님은 Classicist 쪽에 속하셔서 Service를 테스트할 경우 Repo도 포함한다고 하셨었는데 Controller에서는 MockMvc를 활용하셔서 따로 테스트한 것으로 알고 있습니다.컨트롤러 - 서비스, 레포지토리의 관계와 서비스 - 레포지토리의 관계에서 어떤 차이점 때문에 이렇게 구성하신 것인지 궁금합니다.

서비스를 소형 단위로 테스트하기 위해 Fake 클래스를 구현하는 실습을 진행하셨는데요.테스트 코드는 결국 구현된 기능이 정상적으로 동작하는지 검증하기 위한 것이라고 생각하는데요~그런데 H2 DB를 직접 띄워 테스트하는 방식과 비교했을 때, Fake 객체를 활용한 방식은 구현 방식에 따라 실제 동작과의 괴리가 생길 수도 있을 것 같은데, 이런 접근이 실제로 효과적인 테스트 방법인지 궁금합니다!

강의를 들으며 제일 강조하시는게 "요구사항 충족" 이라고 생각했습니다. 처음부터 아키텍처를 정해놓지 않은 상태로 요구사항 충족을 목표로 달리는 형태로 설명해주셔서 TDD의 의미나 철학을 이해하는데 도움은 많이 됐습니다!궁금한 것은 현업에서도 새로운 프로젝트를 시작할때 이와 같은 방식으로, 아키텍처를 특별히 정해놓지 않고 개발하는것이 일반적인가요? 테스트 표면을 통해 아키텍처를 유연하게 변경 가능하다고 하신 말씀도 이해를 했는데 서비스 기획 및 설계 단계에서 서비스의 성격/특성에 맞추어 아키텍처정도는 어느정도 정하고 가는것도 괜찮지 않을까 생각하여 여쭤봅니다!!

안녕하세요, 강사님! Spring Boot TDD 강의 정말 잘 듣고 있습니다. 강의 내용 중 궁금한 점이 생겨 질문드립니다.보통 Spring에서 개발할 때 Controller-Service-Repository 구조의 레이어드 아키텍처를 많이 사용하는데요, 강의에서는 컨트롤러가 직접 리포지토리의 save 같은 메서드를 호출하면서 비즈니스 로직을 처리하는 경우가 있는 것 같습니다.혹시 이것이 강의의 핵심 내용에 집중하기 위해 코드를 단순화하신 것인지, 아니면 강사님께서 실제로 선호하시는 개발 스타일이신지 궁금합니다. 만약 후자라면 어떤 장점이 있는지 그 이유에 대한 의견을 여쭙고 싶습니다.더불어, "TDD를 잘하려면 인터페이스를 많이 사용해야 한다"는 것이 일종의 오해라는 말씀에 크게 공감했습니다. 그런데 왜 개발자들 사이에서 이런 오해가 생겨나게 된 것인지 그 배경이 궁금합니다.마지막으로 추후에 비즈니스가 복잡해지면 테스트가 깨졌을 때 어디가 문제인지 파악이 어려울 것 같은데요 이에 따른 문제를 어떻게 해결하시나요? 단위테스트를 추가로 작성하시는지도 궁금합니다.

ERD 가장자리에 있는 도메인들은 선행적으로 존재해야하는 도메인들이 있다보니 테스트 코드 작성 시 given 부분이 너무 길어져요.어떻게 짜는게 좋은지 의견 부탁드립니다!!

안녕하세요, 강사님. TDD 관련 강의 항상 잘 듣고 있습니다.강의 내용을 따라 실습을 진행하던 중, 테스트 격리 전략에 대해 궁금한 점이 생겨 질문 남깁니다. # 강의에서 다뤄주신 상황강의에서처럼 여러 테스트 메서드에서 동일한 이메일 값을 사용하니, 테스트 클래스 전체를 실행했을 때 JPA의 유니크 제약 조건 위반 에러가 발생했습니다. 이로 인해 개별 테스트는 성공하지만 전체 테스트는 실패하는 상황에서 궁금증이 생겼습니다. # 제가 먼저 생각한 해결책: @Transactional을 이용한 롤백저는 강의를 들여면서 이 문제를 해결하기 위해, 각 테스트 메서드에 @Transactional 애너테이션을 붙여 테스트가 끝나면 자동으로 롤백시키는 방식을 먼저 떠올렸습니다. 이 방법으로 각 테스트가 독립적인 트랜잭션 내에서 실행되고, DB 상태를 다음 테스트에 영향을 주지 않는 상태로 유지할 수 있다고 생각했습니다. ##강사님의 방식(임의 데이터 generator)에 대한 질문##그런데 강사님께서는 강의에서 롤백 방식을 사용하지 않으시고, UUID 등을 활용해 매번 고유한 이메일 주소를 생성해주는 데이터 제너레이터 방식을 사용하셨습니다. 강의에서도@Transactional 을 성능 등 여러가지 이유로 인해 사용하지 않았다고 하셨는데요.@Transactional을 이용한 롤백 방식도 충분히 좋은 해결책이라고 생각했는데, 강사님께서 UUID 생성 방식을 선택하신 특별한 이유나 설계 철학이 궁금합니다.혹시 제가 생각한 롤백 방식에 비해 UUID 생성 방식이 갖는 실용적인 장점(ex. 롤백을 하지 않으니 디버깅의 용이성(?))이 있을까요? 두 방식의 장단점과 어떤 상황에서 어떤 전략을 선택하는 것이 실무에서 더 좋을지에 대한 강사님의 고견을 듣고 싶습니다. 감사합니다!

강의를 들으면서 내부 설계에 의존하는 테스트라는 것이 무엇인지 조금 헷갈려서 질문 드립니다. 강의 초반에는 테스트가 내부 설계에 의존해서는 안된다고 말씀 주셨습니다. 내부 설계에 의존하게 되면 테스트가 깨지는 등의 부작용이 발생할 수 있기 때문이라는 점도 함께 말씀 주셨는데, 이번 강의에서는 내부 설계에 의존해야 하는 케이스를 설명 해주셨습니다. 다만 왜 이런 케이스에는 내부 설계에 의존해야 하는지를 확실하게 이해를 하지 못했습니다. 조금 더 자세한 질문을 드리자면내부 설계의 의미내부 설계에 의존해야 하는 이유이 두가지를 잘 이해하지 못한 것 같습니다.내부 설계라는 것이 클라이언트가 실제로 사용하는, 외부로 공개된 인터페이스를 제외한 모든 부분을 말하는 것일까요? 이번 강의에서 내부 설계에 의존해야 하는 이유는클라이언트는 어떤 방식으로 암호화를 하는지 알 필요가 없다.하지만 현재 공개된 인터페이스로는 실제 비밀번호가 평문으로 저장이 되었는지, 아니면 정말 암호화가 이루어져 저징이 되었는지를 확인할 수 있는 방법이 없다.그러므로 실제 암호화 로직을 테스트 해야한다 (내부 설계에 의존해야 한다)정도로 이해했습니다만 제가 맞게 이해한 것인지 감이 오질 않습니다. 요약하자면내부 설계란 외부로 드러난 인터페이스 외적인 것들을 말하는 것인지왜 내부 설계를 의존해야만 하는 상황이 발생하는지정도일 것 같습니다. 감사합니다.

테스트와 코드간 성장 헙력 관계를 보면서 문득 궁금증이 들었습니다. 테스트 시나리오는 작성하면서 시나리오의 순서 역시도 중요하지 않을까? 하는 의문이 들었습니다. 단순한 기능들은 (예시로 들어주신 회원가입)은 테스트 시나리오의 순서에 큰 영향을 받지 않을 것 같으나 좀 더 복잡한 로직, 예를 들면 금액 계산과 같은 로직은 테스트 시나리오를 작성함에 있어서 순서를 신경 써야 할까요? 좋은 예시가 떠오르지는 않지만예약 시스템을 만들면서 테스트 시나리오를 짠다고 했을 때 테스트 시나리오의 순서대로 코드가 성장이 된다고 가정하면 테스트 시나리오를 작성하는 순서 역시도 중요한 부분 중 하나일 수 있겠다는 생각이 들었습니다.강사님은 테스트 시나리오를 작성 하실 때 순서를 크게 신경 쓰지 않으시나요? 아니면 로직의 흐름을 미리 어느정도 파악해 두시고 시나리오를 그 흐름에 맞춰 작성하시나요? 두서 없는 질문이라 정말 죄송합니다.

@SpringBootTest 어노테이션에 classes를 사용해 CommeceApiApp.class를 구체적으로 지정하시는 이유가 있으실까요?

섹션 2 강의를 듣고 난 후 퀴즈를 푸는데 다음과 같은 문제가 나왔습니다. 소프트웨어 테스트에서 코드의 실제 문제는 있지만 테스트 결과는 성공으로 나타나는 오류 유형은 무엇일까요?문제를 읽다보니 거짓 음성과 거짓 양성이 헷갈리기 시작했습니다.시스템에 문제가 있으나(코로나 양성) 테스트(코로나 검사)는 시스템에 문제가 없다(코로나 음성)라고 나왔으니 거짓 음성이다. 라고 이해하면 되는 것일까요?

안녕하세요 e2e 테스트는 비용이 많이 들어서 어떻게 관리를 하는지 궁금합니다. - 파이프라인에서 매번 CI 에서 돌리기에는 서버나, 시간이 개발 생산성을 잡아 먹을 것 같은데요. 점점 e2e 테스트가 쌓여 나갈떄 어떤 전략을 취할 수 있는지 궁금해요. GPT로 리서치하니까 보통 2가지를 병행해서 스케줄러 + 온디맨드 실행 같이 관리 한다고 하는데, 실제 현업에서는 어떻게 활용하고 계신지, 제가 리서치한 내용 말고 더 효율적이거나, 추천할만한 전략 , 이외의 고려사항 소개해주실 수 있으면 알려주시면 감사하겠습니다.스케줄 실행 (Nightly/주말 풀스윗)EventBridge → ECS Fargate RunTask(Spot 가능) → Playwright 러너대상: 스테이징(or PR 프리뷰 URL)b. 산출물: 트레이스/비디오/리포트 S3 업로드, Slack에 요약/링크온디맨드 실행 (PR 코멘트/수동 트리거)Bitbucket Pipeline에서 aws ecs run-task 호출(또는 ChatOps 슬래시 커맨드)태그/폴더/샤드 인자 넘김 → 필요한 부분만