인프런 커뮤니티 질문&답변

안녕하세요. exbe님, 공식 서포터즈 y2gcoder입니다.

해당 부분은 사람마다 생각이 다르니 개인적인 의견으로 참고만 해주시면 감사하겠습니다!

저는 api의 request를 위해 사용하는 DTO 클래스는 보통 프레젠테이션 레이어에 작성하고, 다른 곳에서 의존하지 않기 때문에 setter나 builder를 열어놔도 상관이 없다고 생각합니다. 해당 request 객체를 비즈니스 로직에 가져와서 수정하거나 하는 등 여러 곳에서 의존성이 생긴다면 그때는 문제가 생길 수 있으나 보통 request 객체는 프레젠테이션 레이어에서 요청 파라미터 바인딩, 파라미터에 대한 간단한 유효성 검사가 주 기능이라고 생각하기 때문입니다.

그리고 별개로 테스트 코드를 작성하기 위해 설계 코드를 변경해도 될까라는 고민에 대해서는 개인적으로 다음 링크(클릭) 에서의 말씀에 동의합니다! 참고해보시면 좋을 것 같습니다 🙂

마지막으로 만약 @WebMvcTest를 붙여 프레젠테이션 레이어의 테스트를 진행하고 계신다면 body 부분을 Map의 형태로 하여 요청을 보내보시는 것도 추천합니다. 그렇게 했을 때는 주저하고 계신 DTO의 구현을 변경할 필요도 없어지기 때문에 괜찮다 생각합니다! 다음 링크(클릭)의 3. 유스케이스 테스트 코드 작성하기 를 참고해보시면 좋을 것 같습니다!

감사합니다.

안녕하세요, 인프런 AI 인턴입니다. exbe님.

테스트 코드를 작성할 때 DTO에 테스트를 위한 생성자나 빌더를 추가하는 것이 고민이 된다는 부분, 충분히 이해가 됩니다. 실무에서도 이러한 고민은 자주 발생하는데요.

일반적으로, DTO(Data Transfer Object)는 계층 간 데이터 교환을 위해 설계되었기 때문에, 읽기 전용 속성을 갖도록 설계하는 경우도 많습니다. 즉, Getter만 열어두는 경우가 다수입니다. 이런 상황에서 테스트 코드를 위해 생성자나 빌더를 추가하는 것이 불편하게 느껴질 수 있습니다.

하지만 테스트가 필요한 경우, 코드의 유지보수성을 해치지 않으면서도 테스트 코드를 작성하는 데 필요한 최소한의 수정을 가하는 것은 흔한 일입니다. 특히나 테스트 코드에서 객체 생성을 보다 간편하게 하는 빌더 패턴은 많이 사용됩니다. 이를 통해 테스트 코드의 가독성을 높이고, 중복을 줄일 수 있으며, 객체 생성의 유연성을 높일 수 있습니다.

다음은 이미 존재하는 비슷한 상황에 대한 지식공유자님의 답변을 참고하시면 도움이 될 것 같습니다:

• Entity 설계 시 고민되는 부분 문의드립니다.(@Setter, @Builder 미사용 시 테스트 등): 여기서 김영한 님은 생성자가 얼마나 중요한지와 상황에 따라 선택할 수 있음을 설명하셨습니다.
  
• Setter 대신 생성자 방식과 @Builder 방식의 선호도: 실제 프로젝트에서 어떻게 접근할 수 있는지에 대한 여러 가지 의견이 제공되고 있습니다.
  

이 답변들이 여러분의 상황에 맞는 적절한 선택을 하는 데 도움이 되길 바랍니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.