테스트 개인과제 진행
테스트 코드를 작성하다가 아주 모르겠는 문제에 직면했다. 문제가 무엇이냐? 바로 RequestDto는 초기화 어떻게 하지??
RequestDto는 클라이언트단에서 바디에 JSON형식으로 데이터가 넘어오고, JSON형식으로 넘어온 String값을 Object Mapper가 객체로 맵핑해주는 걸로 알고 있다. 따라서 RequestDto는 태생적으로 Setter도 생성자도 없다. 그렇다면 테스트할 때 RequestDto는 어떻게 초기화 해야되는거지??
첫번째 안. Setter(생성자) 만들기
간단히 @Setter 어노테이션 하나만 달아주면 끝이다. 근데 의문이 생긴다. 테스트를 위해서 문제없는 코드를 수정하는게 맞나? 의문이 들어 튜터님께 질문 하러 갔다. @Setter든, 생성자를 만들든, 테스트를 위해 RequestDto에 코드를 추가하는게 맞는지? 여쭤봤다. 답은 그런 방향은 좋지 않다. 그러면 어떻게 해야 되냐? 튜터님도 여기에 대한 답이 늦었다.
최종적으로 들은 답은 인자로 RequeestDto를 받지 말고, 필드값을 직접 받아라
예를 들어
public updateUser(User)
public updateUser(UserRequestDto requestDto){
this.nickname = requestDto.getNickname();
this.profile = requeestDto.getProfile();
}
//////////////////////////// 이렇게 말고 ////////////////////
public updateUser(String nickname, String profile){
this.nickname = nickname;
this.profile = profile;
}
/////////////////////////// 이렇게 해라 //////////////////////근데 여기서 다시 의문이 생겼다. 테스트를 편하게 하기 위해서 본 코드를 더 복잡하게 짜야 하는건가..?
싶어서 같이 공부하는 팀원들과 얘기를 나눴다. 우리 아빠동근님이 @Setter를 달고 쓰는것도 고려할만한 선택이다. 라고 하셨다. 나도 튜터님의 얘기와 동근님의 얘기를 들으면 명확한 한가지 답이 있는 것 같지 않다. 내가 어떤 방식을 고를지가 중요한 것 같다. 튜터님의 말을 들으면 테스트에는 용이하겠지만, 본 코드를 작성하는게 복잡해진다. 하지만 동근님의 말처럼 Setter를 달면 RequeseDto에 불필요한 코드가 발생하지만? 그만큼 테스트에는 편해진다. 나는 그래서 @Setter를 쓰려고 한다.
