들어가며 이전에 Oauth 로그인을 전략 패턴을 활용해서 로직을 분리했다. (https://brightstarit.tistory.com/58) 결과적으로 공통 로직과 provider별 다른 로직을 분리해 낼 수 있었고, 추가적으로 내가 제어할 수 없는 로직을 분리했다. 이제 테스트를 진행하려는데 맞닥들인 문제가 있었다. Mockmvc 테스트를 진행하면서 내가 제어할 수 없는 부분은 어떻게 처리해야 할까? Map으로 동적으로 사용할 빈을 결정하는 경우 Stub을 어떻게 해야 할까? 이 두 문제를 해결함으로써 좀 더 테스트를 진행할 때 문제에 더 유연하게 대처가 가능해질 것 같다. 내가 제어할 수 없는 코드 테스트 다음은 우리 서비스의 /api/login을 호출했을 때의 코드이다. @Override publ..
들어가며 이전에 Qhoto에서 구현했던 Oauth2.0을 구현하면서 아쉬웠던 점이 있었다. Qhoto에서는 모든 로직을 GoogleLoginService, KakaoLoginService 함수 안에 중복된 로직이 존재했고 다른 Provider를 추가한다면 계속해서 중복된 로직을 작성해야 된다는 단점이 있었다. 사실 Oauth2.0을 구현하다 보면 Google, Kakao, Naver 등과 같은 Provider의 인증과정이 비슷하다는 것을 알 수 있다. 그리고 인증에 성공했을 때, 처리해야 하는 과정은 모든 Provider가 일치한다. 그럼 모든 공통된 로직과 Provider의 구현 전략들을 분리해 낼 수 있겠다는 결론에 도달했다. 디자인 패턴 중 어떤 디자인을 패턴을 적용해야 할까? 생각이 난 것은 템플..
프로젝트 설명 프로젝트 기간 : 2022년 10월 10일 ~ 2022년 11월 25일 역할 : backend, devOps 활용 기술 : Spring, MySQL, Spring data JPA, QueryDSL, Jenkins, AWS Youtube Shorts, Instagram, TikTok 과 같은 SNS 들은 컨텐츠 소비는 사용자 친화적이지만 컨텐츠를 생산하는 데는 장벽이 있습니다. Qhoto는 관리자가 사용자들에게 SNS에 올릴 컨텐츠를 제공함으로써 생산자와 동시에 소비자가 될 수 있도록 합니다. 동시에 매일 똑같은 하루를 보내는 사람들에게 환경, 건강, 봉사 등 사회에 이로운 퀘스트를 줌으로써 사회공헌과 함께 지루한 일상에 재미 포인트를 줄 수 있는 경험을 제공합니다. github : http..
