feat: 개발서버 테스트 환경 개선 #683
feat: 개발서버 테스트 환경 개선 #683
Conversation
| @Bean | ||
| @Profile({"default", "dev"}) | ||
| public AuthClient testAuthClient() { | ||
| log.warn("테스트 인증 환경이 설정되었습니다. 프로덕션 환경이라면 서버 중지가 필요합니다."); |
| @@ -20,10 +24,18 @@ public class AuthClientConfig { | |||
| private Duration readTimeoutLength; | |||
|
|
|||
| @Bean | |||
| public AuthClient authClient() { | |||
| @Profile("prod") | |||
| public AuthClient realAuthClient() { | |||
There was a problem hiding this comment.
| public AuthClient realAuthClient() { | |
| public AuthClient prodAuthClient() { |
이런 네이밍은 어떨까요?
There was a problem hiding this comment.
Real, External, Prod, Oauth 고민하다가 prod 와 real이 남았서 고민했었는데 메이슨 덕분에 네이밍 고민이 줄어들었네요 ㅎㅎ
prod 프로파일과 동일한 명칭이면 사용할 때 햇갈리지 않을 것 같아요
그럼 testAuthClient도 일관성에 맞게 devAuthClient로 변경할까 고민이네요..
There was a problem hiding this comment.
일관성 있게 devAuthClient로 변경하는 것 찬성합니다! testAuthClient라는 명칭을 사용할 경우 dev 환경이 아닌 저희 로컬 테스트 환경으로 오해될 소지가 있는 것 같아요 :)
There was a problem hiding this comment.
오 답변을 못 드렸었네요! 죄송합니다. 저도 devAuthClient 좋은 것 같아요.
There was a problem hiding this comment.
오 그럼 devAuthClient, prodAuthClient 채택하겠습니다 의견 주셔서 고마워요 😄
|
안녕하세요 에버 잘지내시죠? ㅎㅎ 1번 답변은 이해하신대로 dev 테스트 환경이 맞습니다. 추가로 local에서 실행해도 dev 테스트환경과 동일하게 적용됩니다. |
그럼 로컬 테스트 환경에서 매번 카카오 인증 로직에 접근하는 것인가요? 만약 그렇다면 매 테스트마다 외부 API에 의존하게 되는 것인데, 제가 잘못 이해한 것인지 궁금해요! |
📌 관련 이슈
close #680
✨ 작업 내용
2개의 커밋에 아래의 방식을 적용했는데요, 어느 것을 더 선호하는지 의견 부탁드립니다 🙇테스트 환경 로그인 방식
현재는 아래와 같은 방식으로 인증이 진행되요.
두가지 방식을 고민했어요.
최종적으로 2번을 선택했는데 이유는 1. 안드 친구들의 테스트의 용이성, 2. fcm 토큰 중복으로 인한 로그인 API 실패 때문이에요.
백엔드 입장에선 swagger를 활용하여 accessToken값만 변경하여 로그인 및 회원가입이 용이하나, 안드로이드 폰으로 테스트 하면 매번 다른 accessToken을 받게 되서 기존 테스트로 사용한 계정을 사용할 수 없는 것이 큰 단점으로 다가왔어요.
fcm 토큰은 2개의 계정이 가질 수 없더라구요 즉, Unique 제약 조건을 가집니다.
TLDR; 처음에 이를 해결하기 위해
AuthService의checkFcmToken을 추상화 하는 방식을 생각했어요. 제 입장에선 fcm 상관 없이 api 기능만 테스트하면 된다고 생각했어요.하지만, 개발서버에서 fcm 서비스가 제대로 동작하는지 확인하기 위해선 실제 fcm 서비스를 사용해야 하니까 실제 fcm을 등록해야 하는 경우가 생기게 되므로 이를 호환하기 위해선 기존 카카오톡 로그인을 유지하면서 api 테스트를 용이하게 해야할 필요가 있어서 추상화 하지 않았습니다.
📚 기타