Replies: 8 comments
-
질문 : 테스트에 사용하는 답변: 실제 실행된 결과와 테스트 상 결과가 다를 수 있어 주의가 필요하다. 링크: woowacourse/spring-roomescape-admin#108 (comment) 답변: 링크: woowacourse/spring-roomescape-admin#89 (comment) 질문: dto를 어느 패키지에 주로 두시나요? 답변: 만약 컨트롤러/서비스 레이어가 모두 dto를 알고 있다면, 둘 어디에도 속하지 않는 패키지에 있는 편이 적당할 것 같고 컨트롤러만 dto를 알고 있다면 컨트롤러 패키지 안에 들어와도 괜찮겠죠. |
Beta Was this translation helpful? Give feedback.
-
reviewer: PreparedStatement의 역할은 무엇일까요? 왜 prepareStatement 사용하여 쿼리를 생성해야 할까요? reviewee: PreparedStatement으로 동적으로 쿼리를 사용할 수 있습니다. 즉, DB의 Statement 캐싱 기능을 활용할 수 있습니다. 아래 쿼리는 파라미터만 달리하여 같은 쿼리를 사용하고 있으므로 PreparedStatement를 사용하는 게 적절합니다.
link: woowacourse/spring-roomescape-admin#95 (comment) reviewer: uri 의 마지막에 / 가 들어가지 않는 이유는 무엇인가요? reviewee: 스프링 부트 3.0부터 reviewer: link: woowacourse/spring-roomescape-admin#48 (comment) reviewer: Thymeleaf를 사용했을 때 view가 렌더링되는 과정 reviewee: 길어서 링크로 대체 link: woowacourse/spring-roomescape-admin#48 (comment) reviewer: reviewee:
추가 학습 limit 1도 exists와 비슷한 성능과 결과를 가져오지만 order by를 수행하면 더 느릴 수 있습니다 link: woowacourse/spring-roomescape-admin#144 (comment) reviewer: 데이터를 제거할 때 drop table, delete, truncate 등등 여러 방식이 있었을 텐데 해당 방식을 취하신 이유가 궁금합니다. reviewee:
link: woowacourse/spring-roomescape-admin#144 (comment) reviewer: 고전파와 런던파 사이의 다른 기준
런던파는 단위 테스트는 하향식 TDD로 이뤄지는 것 같아요. 특정 Service 를 만든다고 하면, 가장 큰 책임을 담당하는 객채부터 만들고 의존성이 필요한 객체에 대해서는 모킹하면 되니까(모든 협력자를 차단해 해당 협력자의 구현을 나중으로 미룸) 요구사항을 구현하기 위한 세부 설계에 대한 감이 잡히지 않을 때 저는 주로 런던파 형태로 작업을 하는 것 같아요. 반면 고전파 방식으로 할 때는 고전파는 테스트에서 실제 객체를 다뤄야 하기 때문에 일반적으로 상향식으로 한다. 그렇다보니 요구사항을 개발할 때 필요한 객체에 대한 설계가 어느정도 진행되어 있을 때 가능한 방식인 것 같아요. 테스트명세가 드러나지 않기 때문에 세부사항과 결합되지 않는 장점이 있지만, 일반적으로 객체 설계를 완벽히 하기 어렵기 때문에 해당 테스트 작성을 할 때는 시간이 오래걸리는 편 이에요. 저자는 고전파이신것 같지만,, 초심자들이 접근할 때도 그렇고 빠르게 구현해야할 때는 런던파가 더 접근하기 용이한 것 같습니다! 현업에서는 소나를 적용해서 PR 을 올릴 때 기존 테스트가 동작하는지를 꾸준히 확인하는데요. |
Beta Was this translation helpful? Give feedback.
-
저도 가독성과 인수 테스트 편리함의 장점이 있다고 생각하여 보통 전체를 명시하는 편입니다. woowacourse/spring-roomescape-admin#134 (comment)
식별 관계는 부모 테이블의 키를 자식테이블이 자신의 기본키로 사용하는 관계입니다. 비식별 관계는 부모 테이블의 키를 자식테이블이 자신의 기본키로 사용하지 않고 외래 키로 사용하는 관계입니다. 현재는 예약 시간 없이 rervation_time_id의 값을 null로 해놓고 예약 정보를 insert 해도 정상적으로 들어가는 것을 볼 수 있어 비식별관계로 테이블이 구성되어있습니다! woowacourse/spring-roomescape-admin#134 (comment) 동일한 질문에 대한 다른 크루의 답변 : woowacourse/spring-roomescape-admin#109 (comment)
인터페이스는 도메인 패키지, 인터페이스의 구현체는 영속 계층 패키지에 구분해주었습니다. 서비스 레이어의 의존성을 도메인 하나로 집중 시킬 수 있다. 협업 관점에서 분리하는게 나을 것 같다..? woowacourse/spring-roomescape-admin#121 (comment)
회사마다 정책이 다르기 때문에 확답을 드릴 수가 없네요. 저는 보통 HttpStatus의 정의된 내용을 활용하는 편입니다. 만약, 에러 코드를 정의한다면 동일한 4xx 에러임에도 Client에서 다르게 처리되어야하는 경우가 있습니다. 어느 회사에서는 001: SMS 전송 에러 / 002: fail body 없음 등으로 정의하기도 하고 woowacourse/spring-roomescape-admin#62 (comment) 이후 관련되어 이어지는 리뷰 : woowacourse/spring-roomescape-admin#109 (comment)
Service 계층은 한 마디로 기능을 제공하기 위한 도메인 객체들의 협업이 이루어지는 계층이라고 설명할 수 있을 것 같은데요. 이번 미션에선 도메인 객체들의 협업이 존재하지 않기에, 체스 미션을 잠깐 가져와 보겠습니다. Service 계층의 메서드가 다시 하나의 도메인 객체 메서드로 포워딩 한다면 해당 메서드의 테스트는 도메인 객체의 테스트로 대체할 수 있을 것 같아요. 위의 제 말에 답이 있는 것 같기도 하네요. woowacourse/spring-roomescape-admin#109 (comment)
@SpringBootTest는 실제로 Spring에 의해 의존성이 주입 된 Spring bean을 활용하기 위해 사용한다고 알고 있습니다. 이 때, @SpringBootTest는 기본적으로 모든 테스트에 ApplicationContext 를 공유한다고 합니다. 다만, 제가 사용하고 있는 모든 @SpringBootTest가 @DirtiesContext를 사용하는 것은 테스트를 더 무겁게 만들 것이라 생각합니다. @DirtiesContext를 사용하지 않으려면 각 테스트가 끝난 이후 이전 상태로 데이터베이스를 돌려 주어야 할 것 같은데, 객체가 생성되었다가 삭제되더라도 id 값은 이미 증가된 이후이기에 테스트가 실행되는 순서에 따라 결과가 달라질 수 있을 것 같은데요. 또는 테스트가 종료될 때 마다 테이블 자체를 삭제시키고, 테스트가 시작하기 전에 테이블을 새로 생성할 수 도 있을 것 같습니다만, 좋은 방법일지 고민이 되네요... @transactional을 사용하면 될 것 같기도 한데, 이 키워드가 지금 단계에서의 학습 키워드가 아닌 것 같아서 또 고민이 되기도 합니다. woowacourse/spring-roomescape-admin#109 (comment) |
Beta Was this translation helpful? Give feedback.
-
Reviewer : 하나의 테스트에는 하나의 단언문이 들어가는것이 좋습니다. 이 부분은 온전히 하나의 단언문을 말하는 것이라기 보다 공통된 성격을 띄는 단언문만을 가지고 있어야 한다고 봐주시면 좋을것 같습니다. woowacourse/spring-roomescape-admin#25 (comment) Reviewee : 도메인을 생성할때 필연적으로 id 가 null 이 되는데 해당 부분들은 타협해야 하는 부분 일까요...? Reviewer : 적어주신것 처럼 객체를 나누는 방법도 하나의 객체를 사용 하는 방법도 모두 사용합니다. 근래 헥사고날 아키텍쳐가 유행하며 순수 도메인과 DB용으로 많이 나누기도 하는 편 입니다. 그러나 그러한 경우에도 id는 종종 양쪽 객체에 존재해야하는 경우도 있습니다. 이에대해 더 자세히 알고 싶으시다면 헥사고날 아키텍쳐와 도메인 주도 설계에 대해 공부해보시면 심도있게 탐구하실 수 있을것 같습니다. woowacourse/spring-roomescape-admin#128 (comment) Reviewee : 예약 생성에 대한 API 테스트를 진행할때 어떤 구문을 검증해야 하는지에 대해서 계속 고민을 했습니다.
제 생각으론 Response 의 타입을 확인하는 것 + Response 의 요소를 확인하는 것은 오히려 테스트의 내성을 떨어뜨린다고 생각하여, 해당 로직에 대한 상태코드로 검증을 하는게 맞다 생각하여 statusCode 로 검증을 했습니다. Reviewer : controller의 책임이 응답에 얼만큼 관여하고 있는지에 따라 달라질 수 있을것 같습니다. 가령 controller가 LocalDateTime을 하지만 그렇지 않은 경우, 협력 객체가 전달한 값을 그대로 forwading 하는 경우에는 각 property를 검증하는 것이 생각하신 것처럼 테스트 내성을 저해하는 요소 작용할 수 있습니다. 다만 http status code만 확인하는 것은 조금 위험할 수 있습니다. 해당 API를 통해서 발생하는 부작용들(데이터 생성, 수정, 삭제, 메세지 발행 등)이 있을것 같습니다. 이렇게 부작용으로 인해 변경된 부분에 대해 추상적인 수준에서 검증을 할 필요는 있을것 같습니다. ex. 데이터 생성 API를 호출한 경우,
woowacourse/spring-roomescape-admin#128 (comment) Request DTO와 Service DTO의 분리 Reviewer : service입장에서는 자신을 사용하는 주체가 controller인지 다른 어떠한 객체인지 알지 못하기 때문에 일련의 스펙을 제공하는 것으로 볼 수 있습니다. 말씀하신대로 견고한 클래스가 될 수 있는 장치가 되어줍니다. 모든것은 트레이드 오프의 영역이기 때문에 관리포인트로 보시는것도 일리있습니다. woowacourse/spring-roomescape-admin#128 (comment) |
Beta Was this translation helpful? Give feedback.
-
리뷰어: 엔티티를 도메인과 분리한 이유가 있을까요? woowacourse/spring-roomescape-admin#77 (comment) 리뷰어: controller advice가 전역 핸들러 역할을 하기 때문에 controller 패키지는 적합하지 않다. woowacourse/spring-roomescape-admin#132 (comment) 크루: dto 위치에 대한 고민 woowacourse/spring-roomescape-admin#172 (comment) 크루: 부담을 DB에 줄까 Application 수준에 줄까 |
Beta Was this translation helpful? Give feedback.
-
🏃♂️🦆🔸 RequestMapping으로 최상위 path를 추출했을 때의 장단점
|
Beta Was this translation helpful? Give feedback.
-
리뷰어 : @PathVariable은 parameter이름과 같다면 굳이 name을 넣어주지 않아도 됩니다. 리뷰이 : Build, Execution, Deployment > Build Tools > Gradle > Build and run using에서 Gradle이 아닌 IntelliJ IDEA를 선택한 경우 이러한 문제가 발생할 수 있음을 찾았습니다! 컴파일 시점에 -parameters 옵션을 적용해서 이름 생략 시 오류 발생을 해결하였고, 코드도 이름을 생략하는 방향으로 수정하였습니다. 알아볼 것 : 빌드 환경에 따라 다르게 동작할 수 있다. -parameters 옵션이란 ? ref : woowacourse/spring-roomescape-admin#38 (comment) 리뷰어 : Long / long의 차이는 무엇인가요? 여기서는 무엇을 사용하는게 좋을까요? 리뷰이 : 아래의 내용을 고려했을 때, 예약 삭제에서 id가 null일 경우는 없다고 판단하여 long을 사용하였어요!
알아볼 것 : 래퍼 클래스와 기본 클래스의 차이 ref : 모든 리뷰이에 대해 전반적으로 물어보셨다. 리뷰어 : 그렇다면 testImplementation 을 알아볼까요? 리뷰이 : testImplementation은 테스트 코드를 컴파일하고 실행할 때만 사용되는 라이브러리를 추가하는 데 사용한다는 것을 알 수 있었습니다. 알아볼 것 : 프로덕션 코드와 테스트에서 사용되는 라이브러리를 선택적으로 추가할 수 있다. 해당 미션에서는 h2를 프로덕션에서는 runtime으로, 테스트에서는 testImplementation으로 라이브러리를 import 할 수있음! ref : woowacourse/spring-roomescape-admin#127 (comment) 리뷰어 : ReservationRequestDto 가 api 인터페이스이기도 하고 db처리 인터페이스이기도 하네요. 컨트롤러, db 모두 공통의 객체를 이용하고 있어요. 어떤점이 좋고 나쁠까요? Layered architecture, 계층형 아키텍처는 무엇인가요? 리뷰이 : 계층형 아키텍처 : 관심사를 분리하여 계층형으로 나누어 각 계층 별 역할에 집중할 수 있게 구성하는 설계를 의미한다고 생각합니다. 하나의 DTO를 Controller와 DB모두 사용하고 있을 때 얻을 수 있는 이점으로는 고민해볼 것 : ref : 전반적으로 리뷰이에게 질문한 내용 리뷰어 : RowMapper가 분리된다면 테스트도 가능할것 같아요.(Jdbc dao 코드 내부의 RowMapper) 리뷰이 : 리뷰어 : ref : 알아볼 것 : |
Beta Was this translation helpful? Give feedback.
-
리뷰어 : 테스트를 작성할때는 어떻게 가독성이 보일거냐를 생각하면 좋은데요. "어떤 상황에서 테스트할거냐", "어떤 행위를 테스트할거냐", "그 행위의 무엇을 검증할거냐"가 보통 테스트를 바라볼때 중요한 내용이 됩니다. (bdd(given-when-then)를 타겟해서 이야기하는 것이 아니고 bdd 쓰라고 하는 이야기도 아닙니다.) 링크 : woowacourse/spring-roomescape-admin#54 (comment) 리뷰이 : 이번 단계에서 구현한 코드의 테스트를 작성하면서 어느정도의 테스트를 작성해야할지 고민을 하였습니다. 리뷰어 : 누구는 모든 테스트 커버리지가 채워져야한다라는 분도 계시고 누구는 domain과 service만 테스트해야한다는 사람도 있고, 누구는 프로젝트의 크기가 문제가 아니라 일정때문에 테스트보다 기능이 우선이니 정말 중요한 테스트가 아니고서야 테스트를 작성하지 않는 사람도 있어요. 이 사람들이 다 틀린 말일까요? 테스트를 짜는 관점은 그 관점을 지지하는 이유가 어떻게 잘 설명하고 설득할 수 있느냐에 따라 상황에 따라서 모두 맞을 수 있다고 생각해요. 넘어와서 현재는 실무가 아닌 "미션"이에요. 학습이 메인이죠. 저런 관점은 툭하고 튀어나오는 것이 아닌 이것도 해보고 저것도 해본 결과 이것이 좋다라는 경험이 뒷받침되어야하는데요. 미션인만큼 모든 테스트를 다 작성해보고 나중에 3레벨 프로젝트나 실무에 갔을때 모든 테스트를 다 짜봤는데 이케이스까지만 짜봐도 좋더라정도의 켈리의 주관이 쌓이는 것이 중요하다고 생각합니다. 미션은 실무와 비슷한 개발을 하는 것도 맞지만 그 기반은 학습이니까요. |
Beta Was this translation helpful? Give feedback.
-
_
Beta Was this translation helpful? Give feedback.
All reactions