묻고 답해요
158만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
해결됨오브젝트 - 설계 원칙편
4-2강 음량 작음
왠지는 모르겠으나 4-2강만 음량이 다른 강의 대비 80%수준으로 낮아지는.. 죄송 별걸다..=.=
-
해결됨오브젝트 - 설계 원칙편
3-2 roomAt추출 버그아닌가요
void반환인데 if안에 쓰이고 있는듯 해요.boolean isRoomExist(int x, int y){ return rooms[x + y * width] != null;}이렇게 되야할 거 같은데..
-
해결됨오브젝트 - 설계 원칙편
3-2 언제 추출을 멈출까
메서드가 한가지 이유로 변경될 때까지라는 기준이 모호하기도 하고 약간 실무상으로 반대하는 입장이기도 합니다.우선 한가지 이유라면 이미 run도 한가지 이유(실행하기 위해)welcome도 인사말하기 위해이기 때문에 매우 모호합니다. 반대로 showRoom조차도 일종의 템플릿 메소드 파트와 Room이 처리하는 부분으로 나뉜 것으로 되어있죠.그런 면에서 저는 실무에서 메소드 추출을 멈추는 실제적인 기준을 변화율로 두고 있어요. 그 동네가 한꺼번에 변하냐 아니냐로 보는 방식입니다.만약 welcome수준이 한꺼번에 팀장 회의에서 갈려나가는게 일반적이라면 거기서 멈추고 showRoom에서도 room자체의 설명을 보여주는 부분만 자주 바뀌면 다시 추출하는 방식인거 같아요.
-
해결됨오브젝트 - 설계 원칙편
3-2에서 start() 추출에 대해
지역변수를 필드변수로 승격하는 것에 대한 문제를 생각하게 됩니다.기존에는 running이 지역스코프라 확실하게 문제 범위를 play라고 안심할 수 있었던 것에 비해 필드로 옮겨지면서 왠지//이건 play()에서만 사용됨boolean running;이라고 해야 할 거 같은 느낌이네요.저는 이 경우 스코프 제한을 더 우선 시 하는 편입니다만 이는 이 메소드에서는 괜찮지만 동시성이나 여러가지를 고려하면 더욱 안좋은 습관이지 않냐라는 생각도 듭니다.
-
해결됨오브젝트 - 설계 원칙편
1-1에서 질문있어요.
1-1에서 미래를 예측할 수 없어 실제로 변경이 발생했을 때 적합한 설계로 개선한다고 했는데 이게 약간 도돌이표 느낌이에요.왜냐면 설계를 선택할 때 변경될 가정을 기반으로 한다고 했기 때문입니다.즉 1. 변경 방식에 따라 설계를 선택2. 변경이 발생하면 설계를 변경아니 이러면 변경에 대응하기 위한 설계가 아니라 변경 시 마다 설계를 바꾼다는 것인데애당초 설계를 왜 한 건가 싶은 생각이 맴도는 느낌이네요.저는 설계를 코드를 변화율에 따라 재배치한다고 생각했는데 변화가 일어날 때마다 설계를 변경할 거면 그건 그냥 설계가 아니라 변경에 따라 코드를 수정한 것 같은..
-
해결됨오브젝트 - 설계 원칙편
예제 코드 여는게 너무 불편해요
30개 정도 되는 repo를 하나하나 클론해서 여는게 진짜 너무 불편합니다.폴더 하나에 다 넣어 주시거나 브랜치로 나눠서 제공해주시면 안될까요?
-
미해결실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트
강의 예시프로젝트 업데이트좀 부탁드립니다.
아니면 강의 설명 동영상에프로젝트 초기버전 세팅 등 각종 프로젝트 설정을 자력으로 해야한다. 라는 안내문구라도 존재하면 좋겠습니다. 문제 해결을 할수는 있지만 초기 세팅에 시간이 많이 드는건 사실입니다.
-
미해결Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트
update에서 Repository.save
dbEntity와 도메인으로 따로 분리하면 Jpa의 기능을 쓰지 못하기에 update부분에서 더티체킹을 사용하지 않고 Repository.save를 이용해 merge로 update한다는건데 이렇게 했을 때 merge는 하나하나 다른 부분을 수정하는게 아니고 전부 덮어 쓰는거라 이로 인해 발생할 수 있는 문제에 대해 신경 쓰지 않아도 되나요? 아니면 따로 처리를 해야하나요?
-
미해결Practical Testing: 실용적인 테스트 가이드
계층 관련 질문이 있습니다.
위 강의에서는 Response 부분을 service 레이어에 response 패키지 안에 관리를 하고 있습니다.개인적인 생각으로는 요청을 받는 부분은 최상단 Presentation Layer 이고 궁극적으로 어떠한 결과를 return 해주는 것 또한 Presentation Layer 이라고 생각합니다. 그렇기에 requestDto 는 controller 쪽에 있는게 맞고 responseDto 또한 controller 쪽에 있어야 하는게 맞지 않을까 하는 생각이 듭니다!혹시 위 부분 어떻게 생각하시는지 궁금합니다.
-
해결됨Practical Testing: 실용적인 테스트 가이드
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다
우빈님 안녕하세요! '코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다 ㅎㅎ저도 그동안 실무에서 자바를 쓰면서 테스트에서 given 절의 test fixture는 빌더로 만들어서 사용하고, 프로덕션에서는 팩토리 메서드로 객체를 생성해왔습니다. (물론 이 강의를 보고나서부터입니다 ㅎㅎ) 그런데 코틀린을 쓰다보니까 롬복을 거의 쓸 일이 없는 것 같더라고요.private constructor & 팩토리 메서드를 코틀린에서 쓰다 보니까 팩토리 메서드로만 객체를 생성해야해서 테스트에서 '맥락을 이해하는데 허들이 하나 더' 생기는 꼴이 되고 있어 조금 고민입니다.. 그렇다고 테스트 전용 팩토리 메서드 같은 것을 만들자니 프로덕션에 테스트 관련된 소스가 바로 생기는 것은 영 석연치 않더라고요.그래서 지금은 일단 생성자를 public으로 열어두고, 팩토리 메서드가 있는 도메인 객체를 만들 때는 무조건 팩토리 메서드만 쓴다. 그리고 테스트에서는 테스트 용이성을 위해 생성자로 객체를 생성하는 것을 허용하는 것으로 해보려고 합니다. 혹시 위 같은 상황에서 우빈님은 어떤 기준으로 쓰고 계신지 궁금합니다..!바쁘실텐데도 시간 내어 확인해주셔서 감사합니다 :)
-
미해결Practical Testing: 실용적인 테스트 가이드
혹시 update 로직은 어떻게 테스트하나요? (@Setter?)
강의에선 update 로직이 없어서 테스트할 필요는 없는 것 같은데, 필요한 경우에 엔티티에 @Setter 추가해놓고 테스트 하면 될까요?setter 사용을 지양하라는 글이 많은데, 현업에서는 어떤식으로 테스트하나요?
-
미해결실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트
통합테스트와 단위테스트 파일 분리
통합 테스트와 단위 테스트를 작성할 때 따로 파일 구분 없이 작성하는게 일반적인가요?
-
미해결실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트
grid 양옆에 margin은 어디서 설정되어있는건가요 ?
찾아보니 잘안보여서 네비게이션 밑에 필터부터 전체 마진 양옆으로 먹어진거 ...로우당 그리드 개수 설정이랑 ..
-
미해결Practical Testing: 실용적인 테스트 가이드
단위테스트와 통합테스트의 경계가 궁금합니다.
안녕하세요 우빈님 강의 너무나 잘 듣고 있습니다 🙂주니어에게 큰 힘이 되고 있습니다 감사합니다 공부를 하다보니 단위테스트와 통합테스트의 경계가 궁금하게 되었습니다.우빈님은 컨트롤러 / 서비스 / 리포지토리 각 계층에 대해 단위 / 통합 / 단위 테스트라고 구분하셨는데요 어떤 분은 컨트롤러 계층에서 작성한 테스트에 대해 통합테스트라고 주장하셨습니다@WebMvcTest 또는 @SpringBootTest를 사용해 스프링 컨텍스트의 일부(웹 계층) 또는 전체를 로드해야 한다.진정한 단위 테스트"는 스프링이나 다른 컨테이너 없이 new 연산자를 사용하여 객체를 인스턴스화하고 테스트하는 것을 의미한다고 하셨습니다. 테스트 대상 범위: 또한 테스트는 특정 컨트롤러 메서드의 로직만을 격리하여 테스트하는 것이 아니라, 특정 URL에 대한 HTTP 요청이 스프링 웹 계층을 통과하여 컨트롤러에 도달하고, 컨트롤러의 응답이 HTTP 응답으로 변환되어 반환되는 전체 과정 중 일부를 시뮬레이션하고 검증하는 관점에서 통합테스트다라고 주장하셨습니다. 정확한 구분은 어떻게 해야할까요? 사실 이러한 구분이 중요한가 고민도 됩니다. 어차피 테스트에 대한 목적과 경계 설정을 구분하는 것이 중요하지 않은가 싶긴 한데 우빈님 의견이 궁금합니다.
-
미해결Practical Testing: 실용적인 테스트 가이드
Service+Repository 통합테스트 관련 질문입니다.
요즘 서비스 계층 단위테스트를 위해 모킹과 fake 객체 구현을 공부하고 있습니다. 하지만 레포지토리를 일일이 모킹하는 코드를 작성하는 것이 빠른 피드백이 장점인 단위테스트로 의미가 있는지 의문이 들 정도로 시간이 많이 들더라고요. 그래서, 좀 더 효율적인 강사님의 방식을 따라가고 싶어 강의를 듣던 중 의문이 생겨서 질문드립니다.1. 계층별 테스트 분리 기준에 대한 질문입니다.컨트롤러, 레포지토리는 단위테스트, 서비스 계층은 레포지토리 부분과 통합테스트 이렇게 분리해서 진행하셨던 이유를 여쭤봐도 될까요? 서비스, 컨트롤러, 레포지토리 계층 각각 단위테스트를 작성하고 컨트롤러에서 레포지토리까지 한번 통합테스트를 작성하는 방법도 있을 것 같고, 묶어볼 방법은 몇 가지 더 있는 것 같습니다.그런데 강의에서처럼 분리했던 게 가장 효율적이라고 생각하는 기준과 이유…. 이 분리 방식의 발견 과정이 너무 궁금하네요2. 통합테스트 DB 관련 질문입니다.서비스계층과 레포지토리 계층을 묶은 상태로 H2 같은 임베디드 데이터베이스를 사용하면 테스트 속도가 상당히 느리게 나오긴 합니다. 이런 부분은 어쩔 수 없이 안고 가는 것인가요? 그리고 운영이나 개발 DB를 postgress같이 H2말고 다른 걸 사용한다고 해도, H2로 통합테스트 테스트하는게 이점이 있을까요?3. 서비스 계층 단위테스트 관련 질문입니다.혹시, 부담이 안 된다면, 서비스 계층의 단위테스트가 중요도가 많이 떨어진다고 생각하시는 이유가 Fake든 Mockito를 사용한 Stub이든 데이터베이스를 흉내만 내는 테스트가 의미가 없다고 여기셔서 그런 것일까요?부족한 질문 읽어주셔서 감사합니다!
-
미해결따라하며 배우는 리액트 A-Z[19버전 반영]
안녕하세요 개발과 상관없는 질문입니다만
안녕하세요 강사님 좋은 강의 감사드립니다vscode 테마 정보좀 알수있을까요?
-
미해결Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트
최종 완성된 코드를 받아 볼 수 있을까요?
안녕하세요. 강의 잘 듣고 있습니다^^최종완성된 코드를 받아서 확인해보고 싶은게 있는데 공유 가능할까요?
-
미해결더 자바, 애플리케이션을 테스트하는 다양한 방법
테스트 반복하기 관련 질문입니다
@DisplayName("파라미터 테스트") @ParameterizedTest(name = "{index} {displayName} message={0}") @ValueSource(ints = {10, 20, 40}) void parameterizedTest(Study study){ System.out.println(study.getLimit()); }Junit5 테스트 반복하기 2부에서 이 부분 질문드리려 합니다. 강의에서는 Study 타입으로 받아서 객체를 생성하고 getLimit으로 값 가져오는 것까지 묵시적으로 진행이 잘 되었습니다만, 제 환경에서는 ```javaError converting parameter at index 0: No built-in converter for source type java.lang.Integer and target type com.example.testpractice.Studyorg.junit.jupiter.api.extension.ParameterResolutionException: Error converting parameter at index 0: No built-in converter for source type java.lang.Integer and target type com.example.testpractice.Study at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)``` 와 같은 에러가 발생해서 Junit이나 JDK의 버전에 따라 스펙이 바뀌었는지 궁금해져서 질문드립니다
-
미해결Practical Testing: 실용적인 테스트 가이드
OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요
OrderControllerDocsTest.java@DisplayName("주문 생성 API") @Test void createOrder() throws Exception { OrderCreateRequest request = OrderCreateRequest.builder() .productNumbers(List.of("001")) .build(); LocalDateTime now = LocalDateTime.now(); given(orderService.createOrder(any(OrderCreateServiceRequest.class), any(LocalDateTime.class))) .willReturn(OrderResponse.builder() .id(1L) .totalPrice(4000) .registeredDateTime(now) .products(List.of(ProductResponse.builder() .id(1L) .productNumber("001") .type(ProductType.HANDMADE) .sellingStatus(ProductSellingStatus.SELLING) .name("아메리카노") .price(4000) .build())) .build()); mockMvc.perform(post("/api/v1/orders/new") .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(request))) .andDo(print()) .andExpect(status().isOk()) .andExpect(jsonPath("$.code").value("200")) .andExpect(jsonPath("$.message").value("OK")) .andExpect(jsonPath("$.status").value("OK")) .andDo(document("order-create", preprocessRequest(prettyPrint()), preprocessResponse(prettyPrint()), requestFields( fieldWithPath("productNumbers").type(JsonFieldType.ARRAY) .description("상품 번호") ), responseFields( fieldWithPath("code").type(JsonFieldType.NUMBER) .description("코드"), fieldWithPath("status").type(JsonFieldType.STRING) .description("상태"), fieldWithPath("message").type(JsonFieldType.STRING) .description("메시지"), fieldWithPath("data").type(JsonFieldType.OBJECT) .description("응답 데이터"), fieldWithPath("data.id").type(JsonFieldType.NUMBER) .description("주문 ID"), fieldWithPath("data.totalPrice").type(JsonFieldType.NUMBER) .description("주문 총 금액"), fieldWithPath("data.registeredDateTime").type(JsonFieldType.ARRAY) .description("주문 시각"), fieldWithPath("data.products").type(JsonFieldType.ARRAY) .description("주문 상품"), fieldWithPath("data.products[].id").type(JsonFieldType.NUMBER) .description("상품 ID"), fieldWithPath("data.products[].productNumber").type(JsonFieldType.STRING) .description("상품 번호"), fieldWithPath("data.products[].type").type(JsonFieldType.STRING) .description("상품 타입"), fieldWithPath("data.products[].sellingStatus").type(JsonFieldType.STRING) .description("상품 상태"), fieldWithPath("data.products[].name").type(JsonFieldType.STRING) .description("상품 이름"), fieldWithPath("data.products[].price").type(JsonFieldType.NUMBER) .description("상품 가격") ))); } docs/index.html 에서 확인한 registeredDateTime처음에 테스트 코드 작성시에 ieldWithPath("data.registeredDateTime").type(JsonFieldType.ARRAY) .description("주문 시각"),이 부분을 JsontFieldType.STRING 으로 했더니 테스트 실패 메시지에 해당 타입이 Array 라고 해서 바꿨는데... 문서에 저렇게 나옵니다. 이게 맞는건지 궁금합니다.
-
미해결Practical Testing: 실용적인 테스트 가이드
test 용 .yml
안녕하세요 좋은 강의 감사합니다. 강의에서는 테스트에 사용되는 설정 파일을 main/resources/~.yml 파일을 사용하셨는데요.혹시 test 패키지에 별도의 .yml 파일을 둬서 사용하는 것은 어떻게 생각하시나요?보통 어떻게 하는 것이 올바르고? 장단이 있을지 궁금합니다. 강사님 의견도 궁금하구요! 감사합니다.