FE에서 모킹을 포함한 통합 테스트를 진행할 때, API 요청 전까지의 동작API 요청API 응답API 응답에 따른 화면 변환 1, 4는 테스트에서 주로 다루고 있고,3은 모킹으로 처리하고 있는데, 2번의 경우, 예를 들어 화면에서 필터로 { name: "apple", limit: 10 } 를 설정하고 요청이 발생했으면, request의 parameter에 이런 요청이 도달했다는 것 까지 검증하면 좋을지가 궁금합니다. 생성/삭제/수정과 같은 API가 포함된 경우 동일 GET API라도 다른 응답이 반환되어야 되는 경우가 있어, 해당 테스트 시 응답 자체를 override해서 모킹하여서 작성하였는데, 이 경우 사실상 API 응답과 API 응답에 따른 화면 변환은 테스트가 성공하는 채로 고정하는데, 실제 요청이 올바르게 이루어졌는지는 검증하지 못하는 것 같아서요.

강의자료와 실러버스는 제공되지 않는 건가요?

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

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

아직 선착순이 다 안차서 안올라오는건가요?

await render(<TextField className={'my-class'} />); expect(screen.getByPlaceholderText('텍스트를 입력해 주세요.')).toHaveClass( 'my-class', );이렇게 props를 넘겨줄때 동일하게 작은 따옴표로 넘겨주거나 expect에 들어가는 문자열을 작은 따옴표로 입력을 해야 테스트전 린트에서 잡히는 에러가 안나네요;;

안녕하세요 선생님 mockfunction에 대해서 설명 듣다가 질문이 생겨 글 남깁니다. mockfunction이 좋고 유용한 이유가 기존 함수를 변경할 수 있다는 점이라고 하셨는데 , 기존 함수를 변경해서 테스트를 왜 하는지 모르겠습니다 .추후 강의에서 나오는 부분일까요?  그러니까 "필요성"에 대해서 공감이 가지 않는 것 같습니다,, 개발한 함수가 잘 돌아가는지에 대해서 테스트하면 되는 것인데 왜 다른 함수로 바꿔서 테스트를하나요? 그게 버그잡기 등의 효과가 있나요? 있다면 예를 들면 어떤상황이 있을지 알려주심 넘 감사할것 같습니다. 감사합니다

안녕하세요 선생님 mockfunction에 대해서 설명 듣다가 질문이 생겨 글 남깁니다. mockfunction이 좋고 유용한 이유가 기존 함수를 변경할 수 있다는 점이라고 하셨는데 , 기존 함수를 변경해서 테스트를 왜 하는지 모르겠습니다 .추후 강의에서 나오는 부분일까요?  그러니까 "필요성"에 대해서 공감이 가지 않는 것 같습니다,, 개발한 함수가 잘 돌아가는지에 대해서 테스트하면 되는 것인데 왜 다른 함수로 바꿔서 테스트를하나요? 그게 버그잡기 등의 효과가 있나요? 있다면 예를 들면 어떤상황이 있을지 알려주심 넘 감사할것 같습니다. 감사합니다

영호님 안녕하세요! 이번에는 설계원칙편의 6-1장 강의를 듣던 중, 궁금한 부분이 생겨 질문 드립니다~!! 디미터 법칙을 만족시키기 위해 Game 클래스의 showRoom() 메서드 내부의 구현을 리팩토링 하는 과정에서 player.currentRoom()메서드를 통해 Room 객체에 접근하여 name과 description 정보를 반환받도록 하는 부분이 있었습니다. Q. 혹시 showRoom() 메서드 내부에서 player로부터 Room 객체를 반환 받아 Game객체가 사용하는 것이 아닌, Room에 대한 정보를 Room객체로부터 바로 반환 받도록 하는 것은 어떠신지 궁금합니다!  예를 들어서 Room에 대한 정보를 Room이 책임지도록 하였을 때public class Player { private WorldMap worldMap; private Position position; ... public String currentRoom() { return worldMap.roomAt(position).getRoomInfo(); // 디미터 법칙 준수 } } public class Room { private Position position; private String name; private String description; ... public String getRoomInfo() { return String.format("현재 위치는 %s 입니다. %s\n", name, description); } } Room에 층수 정보와 같이 무언가 추가되는 상황이 발생하더라도 Game에서는 코드를 수정할 필요가 없이 Room 객체 내부에서만 변경하면 될 것 같아보였습니다! 🤔

Visual studio 2017 을 설치할 수 없고,2022로 하니 입력, 출력에 대한 IDE 설정을 할수가 없습니다.다른 좋은 방법좀 알려주실 수 있을까요

안녕하세요 강사님, 강의 잘 보고 있습니다. 이동 로직을 정리하다가 보호(가드) 로직 중복에 대해 질문드립니다.현재 구조에서 Game.tryMove()에서 player.canMove(dir)로 먼저 확인하고, Player.move(dir) 내부에서도 canMove(dir)를 다시 확인하여 막습니다.즉, 이동 가능 여부 판정이 두 번 수행됩니다.// Game private void tryMove(Direction dir) { if (player.canMove(dir)) { // 1차 player.move(dir); // 내부의 2차 showRoom(); } else showBlocked(); } // Player public void move(Direction dir) { if (!canMove(dir)) throw new IllegalArgumentException(); this.position = this.position.shift(dir); } 두 번의 가드가 필요한 이유가 있을까요? SRP/TDA 관점에서는 Game의 판정을 제거하고 player.tryMove(dir)만 호출해 결과만 처리하는 패턴이 더 적절한지, 혹은 move()만 두고 예외로 제어하는 방식을 권장하시는지 궁금합니다. 

안녕하세요. 좋은 강의 감사합니다. 덕분에 객체지향에 대한 이해가 많이 정리되었습니다.3-2 강의를 보다 메서드 크기 관련해서 궁금한 점이 있어 질문드립니다.콘솔 입력 의존성(12:17) 부분에서 입력을 분리하는 예시로 아래와 같이 nextLine() 호출을 별도 메서드로 추출하신 것으로 이해했습니다.private String input(){ return Scanner.nextLine(); }그런데 이 관점이라면, 입력 “수집(I/O)” 뿐 아니라 “입력 파싱(문법)”도 별도의 책임으로 분리해야 하는 것 아닌지 고민이 됩니다. 예를 들어:private String[] inputParsing(String input){ return input().toLowerCase().trim().split("\\s+"); }강사님의 강의 및 "객체지향의 사실과 오해" 책을 읽고 난 뒤, SRP의 책임을 ‘하나의 변경 이유’로 보았습니다.위의 콘솔 입력(nextLine)을 분리한 건 입력 장치 변경이라는 액터에 대한 책임 분리로 이해했습니다.그렇다면 입력 파싱(toLowerCase/trim/split)은 명령 문법 변경이라는 또 다른 액터에 대한 책임이므로, 이 역시 별도로 분리해야 SRP를 완전히 지키는 게 아닐까요? 물론 이렇게까지 분리하면 가독성이 떨어질 수 있고, 실제로는 변경 가능성도 낮아 “가치가 작은 분리”로 느껴지기도 합니다. 강사님의 의견이 궁금합니다!+ 외에도 추상화 수준을 맞추기 위한 메서드 추출(9:25) 강의 자료에isRunning 함수의 반환이 void로 되어있으나 실제 내부에선 running == true를 반환합니다. github 코드 상에는 해당 함수가 없어보입니다.

강사님, 강의 잘 듣고 있습니다.강의 중 jest에서 한글로 적을 때는 test, 영어로 적을 때는 it으로 적는 게 가독성이 좋다고 설명해주셨는데, 실무 팀에서는 이런 네이밍 컨벤션을 어떻게 정하고 유지하는지, 혹시 Prettier, ESLint 같은 도구로 특정 스타일(예: test만 사용)을 강제하는 경우도 있는지 궁금합니다.

안녕하세요. 좋은 강의 감사합니다.값 객체에 대한 내용을 듣고 궁금했던 점이 있었는데, 섹션 4 퀴즈를 풀면서 해소되는 동시에 새로운 질문이 생겼습니다.값 객체를 사용하는 메소드를 과도하게 호출하여 OOM(Out of Memory)이 발생할 것으로 예상되는 경우, 이를 어떻게 회피할 수 있는지 궁금합니다.아직 강의를 전부 듣지 않아서 이후에 나올 내용일 수도 있겠지만, 지금 드는 생각으로는 Map을 이용해 내부적으로 캐시를 구현하여 메모리 사용량을 줄이는 방법이 떠오르는데, 이 접근법이 맞을지 궁금합니다.

선배 개발자로서 알려주시는 강의 내용들이 정말 좋았는데요, 그와 더불어 앞으로 주니어 백엔드 개발자로서 어떤 역량을 조금 더 집중해서 키우면 좋을지 조언을 부탁드리고 싶습니다.또, 아직 이를 수도 있지만 이직을 준비할 때 도움이 될 만한 공부 방향이나 추천해주실 만한 책이 있다면 알려주시면 감사하겠습니다. 강의 중간중간 소개해주시는 책들이 많아서 최근에 또 추천해주실 책이 생기셨는지 궁금합니다.

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

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

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

pdf의 17~18 페이지, 강의의 4:54Reader를 reader 패키지에서 game 패키지로 이동시켜 reader 패키지가 game 패키지를 의존하게 만들 수 있다고 하셨는데 패키지란게 Java의 기능인가요? 그렇다면 C++에 대응될 만한 기능이 있을까요?

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