[스프링] 28. MemberService까지 만들고의 회고, 그리고 search를 마지막까지 다듬어보자!!

일단 MemberService를 다시 돌아보았다. 

validate / domain logic / repository사용을 최대한 분리해 각 메서드를 register에서 7줄 정도를 만든게 최대 길이일 정도로 최대한 잘게 나누어 사용해보았다. 

 

이렇게 되면서, 메서드 재사용성을 확인하고, 각 로직에서 에러가 발생했을 때, 어떤 이유인지 확인하기 용이했던 장점이 있다. 

또한, 로그인 로직에서 Token까지 MemberService로 묶었을 때 하나의 서비스까지 두개의 도메인을 따로 가져와 다 사용한다는게 조심스러웠는데, 이 부분을 나누는데 시간을 많이 쓴 것 같다. 

 

원래 도메인 로직밖에 테스트할 줄 몰랐는데, 이번에 리포지토리, 서비스 테스트에 대해서 연습해보고 적용해볼 수 있어 더 좋았다. 

개인적으로 컨트롤러 로직 테스트를 조금 연습해보고 제대로 프로젝트에 적용해봐야겠단 생각이 들었다. 

 

여기까지 좋은 말 했으면 이제 안좋은 말을 좀 해야겠다. 

지금의 로직을 만들면서, 컨트롤러에서 결국 어떻게 받아 사용할지라던가, 혹은 어떻게 dto를 써먹을지, 어떤 방식으로 도메인을 생성하는게 제일 효율적인지 등을 너무 생각하지 않았다는 생각도 든다. 

조금 더, 로직이 어떻게 흘러갈지 깊게 생각해보고 만들어야 겠다는 생각이 들었다. 

최종적으로 search로직에 대해서 신경이 더 쓰였다. 

 

쓰인 이유를 이야기해보자면, 프로젝트를 개발하는 입장이 아닌, 사용하는 입장에서 한번 검색이라는 기능을 생각해보아야 한다. 

물론 contains를 이용해, 정확한 이름은 모르더라도 검색할 수 있는 기능을 준 것 까지는 좋았다. 

하지만, 하나의 테스트를 만들어보고 문제가 있음을 느꼈다(미리 생각을 더 했어야 한다는 생각도 든다)

이런 테스트의 결과가

나오지 않았다. 

왜냐하면 querydsl을 사용하며 and를 사용했기 때문이다. 

 

과연 사용자가, 정확한 값들을 알고 검색을 할까?

절대 아닐텐데, 이러한 점은 CONTAINS로 사용해도 똑같이 나타난다. 

 

어떤 사용자의 정확한 아이디, 닉네임, 이메일을 부분적으로 아는게 아니라면, 이러한 점은 문제가 될 수 있다. 

그렇다면 이걸 or로직으로 만드는게 맞지 않았을까?

 

이걸 마지막까지 정리하고 이전에 만들려 했던 테스트코드를 만든 후에, 컨트롤러 로직으로 넘어가는게 맞다는 생각이 든다. 

생각보다 만족스럽게 공부를 했지만, 아직 사용하는 방법이 조금 서투르다는 생각이 든다. 

조금 더 숙달된 조교의 시범이 되도록 하겠다. 

군필의 PTSD