해결된 질문
작성
·
410
2
안녕하세요, 강의를 모두 들었고 정말 알차고 재밌게 다 들었습니다. 감사드립니다!
복습을 하다보니 실무 관점에서 몇가지 궁금한 부분들이 있는데요!!
1) JpaRepository 를 구현하는 구현체로 기본적인 CRUD 등 (ex. save(), saveAll() 등) 사용한다면, 이 부분도 별도 테스트를 작성하시나요? 전 이미 제공된 기본 메소드라 테스트 안해도 될 것 같다고 생각드는데 강사님은 실무에서 이부분도 하시는지 궁금합니다.
2) update/delete를 하게되면 저는 보통 void로 리턴값 없이 HttpStatus.ok 코드 정도만 보내곤했는데요. ApiResponse<Void>
이렇게 해서 보내도 무관할지 아니면 처리된 id값 정도라도 응답데이터에 실어서 보내는게 좋은가요?
3) 클라이언트에게 response하고 싶은 데이터가 API마다 다를 수 있는데 그럴때 서로 다른 Response DTO를 각자 만들어서 반환하시는 편인가요??
제가 질문한 부분들은 할려면 다 할 수 있지만 좀 더 실무적인 관점에서의 방법이 궁금해서 여쭤봅니다! 감사합니다!
답변 1
0
안녕하세요, lina님! :)
답변 드리겠습니다.
1) JpaRepository 를 구현하는 구현체로 기본적인 CRUD 등 (ex. save(), saveAll() 등) 사용한다면, 이 부분도 별도 테스트를 작성하시나요? 전 이미 제공된 기본 메소드라 테스트 안해도 될 것 같다고 생각드는데 강사님은 실무에서 이부분도 하시는지 궁금합니다.
제가 강의에서 지나가는 말로 언급했을 수도 있는데, 저도 기본으로 제공되는 메서드는 테스트 코드를 작성할 필요가 없다고 생각해요 ㅎㅎ
제공되는 기능은 이미 검증 자체가 완료된, 라이브러리로 제공되는 기능이기 때문에 굳이 우리가 비용을 들여 테스트를 할 필요는 없는 것이죠 :)
2) update/delete를 하게되면 저는 보통 void로 리턴값 없이 HttpStatus.ok 코드 정도만 보내곤했는데요.
ApiResponse<Void>
이렇게 해서 보내도 무관할지 아니면 처리된 id값 정도라도 응답데이터에 실어서 보내는게 좋은가요?
이 부분은 응답을 받는 클라이언트의 필요에 따라 달라질 수 있는 부분일 것 같아요.
요청에 대한 처리 결과를 받고 싶을 수도 있고, 아니면 서버 입장에서 아무런 정보도 제공하고 싶지 않을 수도 있어서, 상황에 맞게 설계하기 나름일 것 같네요 :)
3) 클라이언트에게 response하고 싶은 데이터가 API마다 다를 수 있는데 그럴때 서로 다른 Response DTO를 각자 만들어서 반환하시는 편인가요??
네, 저는 응답 형태가 비슷하더라도 DTO를 분리하는 쪽을 지양하는데요!
프로덕트의 요구사항은 언제든 변화할 수 있기 때문에, 지금 당장은 동일한 응답 객체를 사용하더라도 프로덕트가 발전하면서 어느 순간에는 두 응답을 분리해야만 하는 상황이 발생할 가능성이 크기 때문이에요.
물론 개발자가 판단했을 때 두 API가 같은 맥락(시나리오) 안에서 밀접하게 움직여서 응답이 완전히 동일하고, 이후에도 변화할 가능성이 적다고 생각하면 같은 응답 객체를 사용할 수도 있을 거고요 ㅎㅎ
도움이 되셨기를 바랍니다.
강의 들어주셔서 감사합니다. :)